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Preface 


intended Audience 


This guide is designed for VMS users responsible for protecting operating 
systems from tampering, observation, or theft of services by unauthorized 
users. The term security administrator is used in this guide to refer to 
the person or persons responsible for system security. 


Document Structure 
This guide consists of the following: 


Chapter 1 discusses levels of security requirements and describes three 
sources of security failures. 


Chapter 2 introduces the reference monitor concept of security design 
and provides an overview of VMS security features. 


Chapter 3 provides general information about system security. 
Chapter 4 describes VMS file protection features in detail. 
Chapter 5 describes general system security features. 
Chapter 6 describes security auditing features. 


Chapter 7 describes how to recognize when a system is under attack 


-and protective/defensive actions available. 


Chapter 8 describes security considerations for systems using 
networking. 


Chapter 9 describes security-related actions specific to clustered 
systems, such as mounting the disks and setting up the authorization 
database. 


Appendix A summarizes all user privileges available on VMS systems, 
what they provide, and who may need them. 


Appendix B describes how to access the user data areas in the User 
Authorization File. 


Appendix C lists the default UIC-based protection that Digital provides 
for system files. 


Appendix D describes how to operate VMS systems in a C2 
environment. 


Appendix E lists audit and alarm messages. 


The Glossary offers definitions of security-related terms introduced in 
this guide. 
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Associated Documents 


To effectively implement VMS security features, you should be familiar 
with the system management information presented in the following 
manuals: 


e Introduction to VMS System Management 

¢ Guide to Setting Up a VMS System 

¢ Guide to Maintaining a VMS System 

Users with a specific interest, such as in networking or clusters, should be 
familiar with the documents provided in the documentation set for their 
areas. Security administrators in VMS networking environments should 


be familiar with the VMS Networking Manual. Security administrators on 
clustered systems should be familiar with the VMS VAXcluster Manual. 





Conventions 


XX 


The following conventions are used in this manual: 


CTRL/x A sequence such as CTRL/x indicates that you must 
hold down the key labeled CTRL while you press 
another key or a pointing device button. 


PF1 x A sequence such as PF1 x indicates that you must 
first press and release the key labeled PF1, then 
press and release another key or a pointing device 
button. 


A key name is shown enclosed to indicate that you 
press a key on the keyboard. 


In examples, a horizontal ellipsis indicates one of the 
following possibilities: 


¢ Additional optional arguments in a statement 
have been omitted. 

¢ The preceding item or items can be repeated one 
or more times. 

¢ Additional parameters, values, or other 
information can be entered. 


A vertical ellipsis indicates the omission of items from 
a code example or command format; the items are 
omitted because they are not important to the topic 
being discussed. 


() In format descriptions, parentheses indicate that, if 
you choose more than one option, you must enciose 
the choices in parentheses. 


{] In format descriptions, brackets indicate that whatever 
is enclosed is optional; you can select none, one, or 
all of the choices. 


red ink 


boldface text 


italic text 


UPPERCASE TEXT 


UPPERCASE TEXT 


numbers 


Preface 


In format descriptions, braces surround a required 
choice of options; you:must choose one of the options 
listed. 


Red ink indicates information that you must enter from 
the keyboard or a screen object that you must choose 
or click on. For online versions, user input is shown in 
bold. 


Boldface text represents the introduction of a new 
term or the name of an argument, an attribute, or a 
reason. 


Italic text represents information that can vary 
in system messages (for example, Internal error 
number). 


Uppercase letters indicate that you must enter a 
command (for example, enter OPEN/READ). 


Uppercase letters indicate the name of a routine, the 
name of a file, the name of a file protection code, or 
the abbreviation for a system privilege. 


Hyphens in coding examples indicate that additional 
arguments to the request are provided on the line that 
follows. 


Unless otherwise noted, all numbers in the text are 
assumed to be decimal. Nondecimal radixes—binary, 
octal, or hexadecimal—are explicitly indicated. 
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Introduction 





Effective operating system security measures help prevent unauthorized 
access and theft of proprietary software, software plans, and computer 
time. These measures can also protect equipment, software, and files from 
damage caused by tampering. 


This chapter provides security administrators with an overview of security 
measures available with the VMS operating system. 





Types of Computer Security Problems 


The source of a security breach on a computer system can usually be 
traced to one of three categories: user irresponsibility, user probing, or 
user penetration. 


User Irresponsibility 


User Probing 


User irresponsibility refers to situations where the user purposely or 
accidentally causes some noticeable damage. An example would be a user 
who is authorized to access certain files making a copy of a key file to sell. 


There is little that an operating system can do to protect sites from this 
source of security failures. The problem frequently lies in application 
design deficiencies or inconsistent use of available controls by users and 
the security administrator. Sometimes the failure to enforce adequate 
environmental security unwittingly encourages this type of security 
problem. 


Even the best security system will fail if implemented inconsistently. This, 
along with the failure to motivate your users to observe good security 
practices, will make your system vulnerable to security failures caused by 
user irresponsibility. 


User probing refers to situations where a user exploits insufficiently 
protected parts of the system. Some users consider gaining access to a 
forbidden system area as an intellectual challenge, playing a game of user- 
versus-system. Although intentions may be harmless, theft of services is a 
crime. Users with more serious intent may seek confidential information, 
attempt embezzlement, or even destroy data by probing. Always treat user 
probing seriously. 


VMS provides many security features to combat user probing. Based on 
security needs, the security administrator implements features either on 
a temporary or permanent basis. These features are discussed in later 
sections. 
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1.1.3. User Penetration 


Penetration refers to situations where the user breaks through security 
controls to gain access to the system. While VMS has security features 
making penetration extremely difficult, it is impossible to make any 
operating system completely impenetrable. 


A user who succeeds in penetrating a system is both skilled and malicious. 
Thus, penetration is the most serious and potentially dangerous type of 
security breach. With proper implementation of VMS security features, 
however, it is also the rarest security breach, requiring unusual skills and 
perseverance. 


1.2 Levels of Security Requirements 


Each site has unique security requirements. Some sites may need limited 
measures because they are able to tolerate some forms of unauthorized 
access with little adverse effect. At the other extreme are those sites 
that cannot tolerate even the slightest probing, such as strategic military 
defense centers. In between are many commercial sites, such as banks. 


To ascertain your security requirements, answer the questions in 
Table 1-1. Your answers may help determine your security needs to be 
low, medium, or high. 


Table 1-1 Event Tolerance as a Measure of Security Requirements 


Level of Security Requirements 


Question: Could You Tolerate Based on Toleration Responses 


the Following Event? 


Low Medium High 
A user knowing the images being 
executed on your system Y Y N 
A user knowing the names of 
another user’s files Y Y N 
A user accessing the file of another 
user in the group Y Y N 
An outsider knowing the name of the 
system just dialed into Y Y N 
A user copying files of other 
users a N N 
A user reading another user’s 
electronic mail Y N N 
A user writing data into another 
user’s file Y N N 
A user deleting another user’s 
file Y N N 


(continued on next page) 


Introduction 
1.2 Levels of Security Requirements 


Table 1-1 (Cont.) Event Tolerance as a Measure of Security 
Requirements 


Level of Security Requirements 


Question: Could You Tolerate Based on Toleration Responses 


the Following Event? 
Low Medium High 


A user being able to read 

sections of a disk that might 

contain various old files Y N N 
A user consuming machine time 

and resources to perform 

unrelated or unauthorized work, 

possibly even playing games Y N N 


If you can tolerate most of the events listed, your security requirements 
are quite low. If your answers are equally mixed between yes and no, your 
requirements are in the medium to high range. Generally, those sites that 
are most intolerant to the listed events have very high levels of security 
requirements. 


When reviewing security needs, do not confuse a weakness in site 

operations or recovery procedures as a security problem. Ensure that 

your operations policies are effective and consistent before evaluating your 
- system security requirements. 


1.3 The Secure System Environment 


There are two sources of security problems outside the operating system 
domain: employee carelessness and facility vulnerability. If you have a 
careless or malicious employee or your facility is insecure, none of the 
security measures discussed in this guide will protect you from security 
breaches. 


Most system penetration occurs through these environmental weaknesses. 
It is much easier to physically remove a small reel of tape than it is to 
break access protection codes or change file protection. 


Digital strongly encourages you to stress environmental considerations as 
well as operating system protections when reviewing site security. 


The following chapters discuss VMS operating system security measures. 
When deciding on which of these measures to implement, it is important 
for you to assess site security needs realistically. While instituting 
adequate security for your site is essential, instituting more security 
than actually necessary is costly and time-consuming. | 
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When deciding which security measures to apply to your system, 
remember the following: 


e The most secure system is also the most difficult to use. 


e Increasing security can increase costs in terms of slower access to data, 
slower machine operations, and slower system performance. 


¢ More security measures require more personnel time. (Increased 
security requires increased employee hours.) 


The VMS operating system provides the basic mechanisms to control 
access to the system and its data. It also provides monitoring tools to 
ensure that access is restricted to authorized users. However, many 
computer crimes are committed by authorized users with no violation 
of the operating system’s security controls. 


Therefore, the security of your operation depends on how you apply these 
security features and how you control your employees and your site. By 
first building appropriate supervisory controls into your application and 
designing your application with the goal of minimizing opportunities for 
abuse, you can then implement VMS operating system security features 
and produce a less vulnerable environment. 


ooo 











2 Overview 


This chapter presents the concepts that guided the design and 
implementation of the security features and mechanisms incorporated 
into the VMS operating system. The intent is to provide a framework for 
thinking about your total system security picture. Subsequent chapters 
present details about the security features and their use. 





2.1 The Reference Monitor Concept 


In the late 1960s, a great deal of research and development was dedicated 
to the problem of achieving security in multiuser computer systems. Much 
of the development work involved attempts to find “all the things that 
could go wrong” with a system’s security and then to correct those flaws 
one by one. It became apparent to the researchers that this process was 
ineffective; effective system security could only result from a basic model of 
the structure of a secure computer system. The reference monitor concept 
was proposed as such a model and gained wide acceptance. 


The reference monitor concept depicts a computer system in terms of 
subjects, objects, an authorization database, an audit trail, and a reference 
monitor mechanism. Figure 2—1 shows the relationship of these elements. 
Subjects are active entities that gain access to information on behalf 

of people, such as user processes. Objects are passive repositories of 
information to be protected, such as files. The authorization database 
defines the system’s security requirements by revealing which subjects 
(acting on behalf of users) can have which kinds of access to objects 

(that contain information). The audit trail maintains a record of access 
attempts, successful or not, as required by the authorization database. 


The reference monitor mechanism enforces the security rules by 
authorizing the creation of subjects, granting subjects access to objects 
according to the requirements of the database, and recording events as 
necessary in the audit trail. In an ideal system, the reference monitor 
mechanism is required to meet the following three requirements: 


¢ Mediate every attempt by a subject to gain access to an object 


¢ Provide a tamperproof database and audit trail that are thoroughly 
protected from unauthorized observation and modification 


¢ Remain small, simple, and well-structured so that effectiveness in 
enforcing security requirements can be assured 
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Figure 2-1 Reference Monitor Diagram 
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A system that meets all requirements of the reference monitor model 
would be very secure. These are the requirements proposed for systems 
that are secure even against penetration. (In such systems, the reference 
monitor is implemented by a security-related subset, or security kernel, 
of the operating system.) While VMS is not such a system, its interface 
to users and system managers does mirror the basic structure dictated by 
the reference monitor concept. Experience shows that incorporating such 
a structure is the best way to build a system resistant to probing and to 
most attempts at penetration. 


The Reference Monitor and VMS 


Subjects 
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The following sections explain the components of the VMS operating 
system comparable to the roles of subjects, objects, authorization database, 
audit trail, and reference monitor mechanism. 


In VMS, the process performs the role of the subject, which is the active 
element that gains access to information. When a user logs in to use 
VMS interactively, or when a batch or network job starts, VMS creates a 
process that includes the identity of the user. That process gains access to 
information as the agent for the user. 


2.2.2 


Objects 


Overview 
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Processes are vuinerabie to security breaches during creation and while 
accessing information. VMS manages process access to information using 
its authorization data and internal mechanisms. Process creation has 
many areas of security vulnerability. For this reason, many of the security 
features in VMS concentrate on the area of process (or subject) creation. 


When a user attempts to log in to VMS, the user provides a user name 
(a name that will be given to the resulting process) and a password. The 
password serves as an authenticator that should be known only to the 
user and to VMS. Because a short or obvious password is likely to fail this 
requirement, VMS incorporates many password protection mechanisms 
that can be invoked by the user or required by the security administrator. 
VMS is also capable of limiting the number of attempts that an intruder 
can make to guess a password. Briefly, then, the association of the user 
with a subject (or process) is a critical aspect of system security. 


The file of users’ passwords is part of the reference monitor’s database 
that must be protected from unauthorized observation and modification. 
VMS attempts to meet this requirement by storing the password in a file 
normally protected from general access, the system user authorization 
file (SYSUAF.DAT). VMS also takes the precaution of storing passwords 
in an encoded form that is not usable if stolen. 


Once it creates a process, VMS assigns that process a User Identification 
Code, or UIC. The UIC corresponds to the name of the user who created 
the process (as authenticated by the user’s password). In addition, the 
UIC indicates the user’s membership in a group that can correspond to the 
user’s department, project, or function. VMS can also attach additional 
information to the process regarding the creation of the process and 

the affiliation of the process owner with other groups. This additional 
information plays a part in the application of the authorization database, 
which is described in a later section. 


In the reference monitor concept, objects are passive repositories of 
information. In VMS, there are many objects subject to protection. The 
most basic (and usually most important) objects in a VMS system are files 
and directories. The VMS operating system protects files and directories 
from unauthorized access and provides a variety of mechanisms (outlined 
in the description of the authorization database) for their controlled 
sharing. 


Objects other than files and directories can also be used to store sensitive 
information. These objects include global sections, mailboxes, logical 
names, event flag clusters, and queues. VMS provides mechanisms to 
protect these objects as well, although these protection techniques may not 
be as complete as those that apply to files. 
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2.2.3 Authorization Database 


2.2.4 Audit Trail 


In the reference monitor concept, each subject’s authorization to gain 
access to an object is found in a single authorization database. In VMS, 
the database is distributed and stored in association with the objects 
that must be protected. For example, the authorization data for a file or 
directory is stored in the file header for that file or directory. 


As the discussion of objects suggested, different objects in VMS can be 
shared with differing levels of flexibility. Almost all objects are subject 
to a UIC-based protection. This form of protection specifies whether 
access is allowed or denied to processes running on behalf of the system 
management, the user who is owner of the object, other members of the 
UIC group of the owner, and all other users. 


In addition to the UIC-based protection, many objects also can be shared 
under control of access control lists (ACLs). ACLs list individual users 
or groups of users who are to be allowed or denied access to the object. 
ACLs specify sharing on the basis of UIC as well as other groupings or 
identifiers that can be associated with a process. For example, it is 
possible to specify that a file should never be read by a process connected 
to a terminal on a dialup line. Section 4.3 describes ACLs and identifiers 
in detail. 


A terminal can be designated as a security alarm console where all 
auditable events are displayed. Some events, such as certain login failures, 
are always auditable. Other events, such as successful or unsuccessful 
attempts to gain access to sensitive files, can be selected by users or 
security administrators for auditing. For example, the owner of a sensitive 
file might create an ACL entry requesting that all accesses to that file be 
audited. 


The audit trail is recorded in the system security audit log file. Under the 
VMS operating system, the following classes of security events are audited 
by default: changes to the authorization, rightslist, and network proxy 
databases, attempted break-ins, and use of the SET AUDIT command. 
Chapter 6 describes security auditing in detail. 


The audit trail mechanism allows users and security administrators to 
record many events. Because it is time-consuming to examine every event, 
it is most efficient only to audit events that will contribute the most 
information to your security picture. 


2.2.5 Reference Monitor Mechanism 
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The VMS executive performs the role of the reference monitor mechanism. 
All system programs that run in kernel and executive mode help 
implement the reference monitor, as do certain user-mode images that run 
with privilege. While the volume of code comprising the VMS executive 

is large, Digital attempts to ensure that none of the code can be used to 
bypass system security. 


2.3 


Summary 


Overview 
2.2 The Reference Monitor and VMS 
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the reference monitor mechanism. For example, a process with the 
BYPASS privilege can gain access to any object without reference to 

the authorization database. Clearly, the granting of such critical privileges 
should be severely limited. 


Similarly, such privileges as SYSPRV and SECURITY are given to users 
whose processes help maintain the reference monitor mechanism and 
database. 


Some VMS nrivileges can grant a nicar tha anthanty ta modify or subvert 
some VM>5 privileges can grant a user 





When designing an overall system security plan, ask yourself the following 
questions: 


¢ How are users associated with subjects? What is the reliability of the 
authentication mechanism? 


e What objects contain sensitive information in this system or 
application? Is access to those objects controlled? 


¢ Does the authorization database reflect policy? Who is authorized to 
gain access to sensitive objects? Are adequate restrictions in place? 


e Is the audit trail recording enough or too much information? Who will 
monitor it? 


¢ What programs are functioning as part of the reference monitor 
mechanism? Which users can modify the mechanism and the 
authorization database? Is this the desired configuration? 


These considerations, as well as the underlying reference monitor concept, 
apply equally to a time-shared VMS system, a widespread network, or a 
single application on a VMS system that grants access to records in a file 
or database. The VMS operating system provides general mechanisms 
that users and system managers must apply to achieve system security. 
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3.1 


3.1.1 


Security for the User 


This chapter provides overall information about security features of the 
VMS operating system and is of interest to all users. By reading this 
chapter and becoming familiar with the additional references for the 
topics provided throughout, the general user should acquire all the basic 
information needed to use the system securely. Whether or not users 
apply this knowledge consistently and accurately while observing the site’s 
specific security policies will make a great difference between a secure 
system and one that is vulnerable. 





Logging In to the System 


Types of Logins 


The actions you perform to gain access to the system are known as logging 
in. The system checks user privilege for the first time during the login 
procedure. During login, users must identify themselves with a user 
name and password. Depending on site security requirements, the login 
procedure can be made more elaborate and can increase user restrictions. 
For example, both primary and secondary passwords can be required. 


VMS recognizes the following seven types of logins: 


¢ Local 

e Dialup 

¢ Remote 

¢ Network 
¢ Batch 

¢ Detached 


e¢ Subprocess 


Logins are either interactive or noninteractive. Interactive logins are 
performed in a series of steps where the system prompts for information 
and the user provides it. Noninteractive logins are performed by the 
system and require no user interaction. Table 3-1 lists interactive and 
noninteractive types of logins. 
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3.1.1.1 


3.1.1.2 


3.1.1.3 


Table 3-1 Classes and Types of Logins 


Login Type 

LOCAL Interactive 

DIALUP Interactive 

REMOTE Interactive 

NETWORK Noninteractive 

BATCH Noninteractive 

DETACHED Dependent on Parent Process 
SUBPROCESS Noninteractive 


The term interactive, as used here, differs from an interactive mode 
process defined by the DCL lexical function FSMODE(). An interactive 
login consists of user input to the operating system that provides the user 
name and password (see Section 3.1.2). An interactive mode process 

is one that is declared to be in communication with a person using 
SYS$COMMAND and may or may not be created by an interactive login. 
However, all interactive logins result in an interactive mode process. 


Local Logins 

A local login is performed by a user from a terminal connected directly 
to the central processor or to a terminal server that communicates directly 
with the central processor. Example 3-1 in Section 3.1.2 illustrates a local 
login. 


A local login is always an interactive login. 


Dialup Logins 

When you log in to a terminal that uses a modem and telephone line to 
make a connection to the computer system, you are completing a dialup 
login. You may execute a few additional steps initially, depending on 

the nature of the terminal concentrator that your system uses. (Since 

the actual procedure is site dependent, it is not described in this guide. 
Your security administrator can provide you with the necessary details.) 
However, once you receive the Username prompt, the basic elements of the 
login are the same as those depicted in Example 3-1 in Section 3.1.2. 


A dialup login is always an interactive login. 


‘Remote Logins 


When you log in to a node over the network, you request that node by 
entering the DCL command SET HOST. This login is known as a remote 
login. The node you reach immediately asks you for a user name and 
password, like the local login illustrated in Example 3-1 in Section 3.1.2. 


A remote login is always an interactive login. 
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Network Logins 

Network logins are performed for you when you access files stored in a 
directory on another node or when you initiate some other type of network 
task on a remote node. Both your current system and the remote system 
must be nodes in the same network. You use one of the DCL commands 
that apply over networks, such as COPY (to copy files between nodes in 
the network) or DIRECTORY (to view files on a remote node). In the 

file specification, you specify the desired node and an optional access 
control string, where the access control string includes your user name 
and password for the remote node. For example, user CRAND has an 
account on remote node PARIS and enters the following command to get a 
directory listing of all the files in the [PUBLIC] directory on disk WORK2: 


$ DIRECTORY PARIS"CRAND password": :WORK2: [PUBLIC]*.*;* 


Proxy logins represent a special type of network login. With a proxy 
login, you also gain network access, but you do not have to include 

an access control string to provide the user name and password for 

your network login request. Thus, proxy logins have several security 
implications. First, passwords are never echoed on the terminal where 
the request originates, which is very desirable. Second, passwords are not 
passed between systems where they might be intercepted in unencrypted 
form. Third, this technique removes the temptation to store passwords in 
command files that would perform the remote access steps. 


Proxy logins are described in Section 3.2.2. 


All network logins are noninteractive. 


Batch Logins 

A batch login is performed for you when a batch process you initiate 
actually runs. For example, you might submit a job to run after 7:00 p.m. 
with the following DCL command: 


$ SUBMIT/AFTER=19:00 PAYROLL.COM 


When the system prepares to execute PAYROLL.COM, the batch job 
controller first logs in to the user’s account to gain access to the program. 
This login is classified as a batch login and is noninteractive. 


The batch job controller does not need a password to perform the login. 


Detached Process Login 

A detached process login occurs as the result of the execution of 
either the process form of the DCL command RUN or the system service 
$CREPRC, where the image specified is SYS$SYSTEM:LOGINOUT.EXE, 
and the options on the service call or the RUN command specify a 
detached process. 


The creator of a detached process login can specify that its type of login is 
either interactive or noninteractive. 
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3.1.1.7 Subprocess Login 
A subprocess login occurs as the result of the execution of either the 
process form of the DCL command RUN or the system service $CREPRC, 
where the image specified is SYS$SYSTEM:LOGINOUT.EXE, and the 
options on the service call or the RUN command specify a subprocess. 
In addition, a subprocess login results when the DCL command SPAWN 
executes. 


A subprocess login is always a noninteractive login. It always runs under 
the account of the creator. 


3.1.2 Interactive Login Informational Messages 


Example 3-1 represents a local login from a terminal directly connected to 
the system and includes examples of most informational messages. 


Example 3-1 Local Login Messages 


WILLOW - a member of the Arboretum VAXCLUSTER @ announcement msg 
Username: RWOODS 
Password: 

You have the following disconnected process: @ disconnected job 
Terminal Process name Image name messages 
VTAS2: RWOODS (none) 

Connect to above listed process [YES]: NO 
Welcome to VAX/VMS Version 5.2 on node WILLOW © welcome msg 


Last interactive login on Wednesday, 1-DEC-1989 10:20 O last login msg 1 
Last non-interactive login on Monday, 30-NOV-1989 17:39 © last login msg 2 
2 failures since last successful login © last login msg 3 


You have 1 new mail message. @ new mail msg 


An announcement message is shown at callout @, disconnected job 
messages at callout @, welcome message at callout ©, and an optional 
group of last login messages at callouts @, @, and ©. If new mail has 
been delivered, users receive a new mail message similar to the one at 
callout @. 


3.1.2.1 Announcement Message 
The announcement message typically identifies the node (and, 
if relevant, the cluster) that you have succeeded in accessing. The 
announcement message is the first visual indication that you have 
initiated the login process. The announcement message immediately 
precedes the Username prompt. Both the appearance and content 
of this message can be controlled by the system manager or security 
administrator redefining the logical name SYS$ANNOUNCE in the site- 
specific startup command procedure (SYS$MANAGER:SYSTARTUP_ 
V5.COM). 
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Disconnected Job Messages 

When you succeed in logging in, you may see messages similar to those in 
Example 3-1 at callout @ reporting disconnected jobs. Such messages 
indicate that a previous login was interrupted prematurely but is available 
for reconnection. These messages appear only when two conditions exist. 
First, the terminal where the interruption occurred must have been set up 
as a virtual terminal to prohibit a process from being disconnected when 
the line sensed a hangup. Second, during a recent session, your connection 
to the CPU through that terminal must have been broken. Refer to the 
Guide to Maintaining a VMS System for information on setting up and 
reconnecting to virtual terminals. 


The disconnected job messages inform you that your process was 
disconnected at some time after your last successful login. You are given 
the option of reconnecting to the old process. Reconnecting returns your 
process to its state before you were disconnected. If you take the default 
action or respond to the question with a “YES” answer, you are logged out 
of your current process as if automatic execution of the DCL command 
CONNECT/CONTINUE had been performed for you. If you specify “no” in 
response to the reconnection question, or you delay too long in responding 
so that a response period timeout occurs, you remain logged in to your 
new process, and you lose the ability to connect to the old process. If you 
have multiple disconnected sessions, you are prompted for the name of the 
virtual terminal to which you want to reconnect. If you do not want to 
connect to any of the displayed sessions, enter “NO.” 


Welcome Message — 

Once you have logged in, you may find a welcome message that indicates 
the software version of VMS that is running and possibly the node name. 
If the system manager chooses, an entirely different message may appear. 
The system manager can also choose to suppress the message entirely. 


Last Login Messages 

Immediately following the welcome message are three messages providing 
information about the last successful login. These last login messages 
are optional. They are enabled or disabled as a group. 


If the messages are enabled, you receive from one to three of the following 
messages: 


e Last successful interactive login message—provides the time of the 
last completed login for a local, dialup, or remote login. (Note that 
logins from a subprocess whose parent was one of these types are 
not included in the count.) An example appears at callout © in 
Example 3-1. 


e Last successful noninteractive login message—provides the time the 
last noninteractive login completed. Noninteractive logins refer to 
batch or network process logins. An example appears at callout © in 
Example 3-1. 
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¢ Number of login failures—if any attempts have been made to log in 
and have failed because of an incorrect password, they are recorded 
in a count displayed in this message at the next successful login. 
To call your attention, a bell rings after the message appears. (An 
incorrect password is the only source of login failure that is counted.) 
An example appears at callout @ in Example 3-1. 


All three types of login message can be displayed at the next successful 
login, whereupon the values for the last successful login and the number 
of login failures are reset. If you always access your account interactively 
and never specify an incorrect password in your login attempts, you 
might never see the last successful noninteractive login and login failure 
messages. 


3.1.2.5 Message Suppression 
A security administrator can suppress the announcement and welcome 
messages, which include node names and operating system identification. 
Because login procedures differ according to operating system, it is more 
difficult to log in without this information. 


Sites with medium- or high-level security needs can display the last login 
success and failure messages. These messages may indicate break-in 
attempts and should be checked each time you log in. They may also 

be a deterrent to potential illegal users by indicating that the system is 
monitoring logins. 


The disconnected job messages appear less frequently and only under 
special circumstances. Virtual terminals must be enabled on your system, 
and the terminal whose connection was broken prior to a logout during 
your last session must also have been set up as disconnectable. The 
security administrator can disable this function by changing the setup on 
terminals and disabling virtual terminals on the system. The ability to 
reconnect is generally desirable and offers no special problems for system 
security. 


3.1.3 Introduction to Passwords 


The VMS operating system requests a password when you log in. 
Passwords are strings of characters that users must specify when they 
log in to show authorization to use the account. To preserve the secrecy of 
passwords, terminals do not echo password characters as they are entered. 
Proper administration of passwords is critical to the security of a system. 


There are several types of passwords on the VMS system. Most users need 
to provide a user password when they log in. Some users also need to 
provide a system password to gain access to a particular terminal before 
logging in with their user password. Users on systems with high security 
requirements need to provide primary passwords and secondary 
passwords. These passwords are described in the following sections. 


The VMS operating system applies a one-way encryption algorithm to 
all passwords as it stores them. Encryption refers to a method of encoding 
information in an effort to conceal it. One-way encryption algorithms do 
not use a key. Thus, even if a malicious user succeeds in obtaining the 
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encryption algorithm and the encoded password, that user could deduce 
the actual password only by trying all possible input values. 


When a user specifies a password, VMS always runs the submitted 
password through the encryption algorithm before attempting to match 
the derived value with the stored value. If the two encoded values match, 
VMS grants access to the user. 


System Passwords 

System passwords control access to particular terminals and are required 

at the discretion of the security administrator. They are usually necessary 
to control access to terminals that might be targets for unauthorized use, 

such as dialup and public terminal lines. 


Your security administrator will tell you if you must specify a system 
password to log in to one or more of the terminals designated for your 
use. Your security administrator will also provide you with the current 
system password, how often it changes, and how to obtain the new system 
password when it does change. 


Specify a system password by pressing the RETURN key until the 
terminal sets the baud rate (called autobauding) and responds with 

the recognition character, which is normally a bell. If your terminal has 
been set with the /NOAUTOBAUD characteristic, you will only press the 
RETURN key once. At that point you type the system password followed 
by RETURN. There will be no prompt and no echo of the characters you 
type. When you succeed in entering the correct system password, you will 
receive the system announcement message, if there is one, followed by the 
username prompt. If you fail to specify the correct system password, you 
can try repeatedly. There is no notification given that you have entered 
an incorrect password. Thus, you might initially think the system is 
malfunctioning unless you know that a system password is required at 
that terminal. 


User Passwords 
Following are the four types of user accounts available on VMS systems: 


e Open accounts require no password; the password is null. Users 
of open accounts are the only users who do not need to enter user 
passwords. The user is not prompted for a password and can begin 
entering commands immediately. 


¢ Captive/restricted accounts may require a password. Captive and 
restricted accounts limit user operations. 


e Accounts that always require passwords and prohibit the user from 
changing the password. The password is locked by setting the 
LOCKPWD flag in the User Authorization File (UAF). By locking 
the password, the security administrator controls all changes made to 
the password. | 


¢ Accounts secured with passwords that are changed periodically by the 
user or security administrator. Because this account type is the most 
commonly used, it is the type referred to in this guide. 
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3.1.3.3 


Typically, when you learn an account has been created for you on the 
system, you are told whether or not a user password is required. If user 
passwords are in effect, you will be told to use a specific password for your 
first login. This password has been placed in your record in the UAF with 
other pertinent information about how your account can be used. 


Often, your first name is used as your first password. This practice is so 
well known that it is undesirable from a security standpoint. Although 
you are requested to change your password as one of your first actions 
after logging in, your account remains highly vulnerable until you do so. 
If there is a time lapse from the time your account is created until your 
first login, other users might log in to your account successfully, gaining 
a chance to damage the system. Similarly, if you neglect to change the 
password or are unable to do so, the system remains vulnerable. Possible 
damage depends largely on what other security measures are in effect. 


It is inadvisable to have accounts on the system where the password can 
be easily guessed. Avoid using the following as passwords: 


e Your name 

e The name of a family member or loved one 

¢ The name of a pet 

¢ The make of your favorite type of automobile 
e The name of your hometown 

¢ The name or make of your boat 


e Any name associated with your work, such as your company, special 
project, or group 


e Any other item that bears a strong personal association to you 
At the time your account is opened, you should also be told a minimum 


length for your passwords and whether you will be able to choose your new 
password or must let the system generate the password for you. 


o 


Changing Your Password 

Change your password using the DCL command SET PASSWORD. This 
command supports two modes: changes entered by the user and automatic 
password generation by the system. The system manager can require that 
you use the automatic password generator when changing your password 
or can allow you to select the method of changing your password. 


User-Selected Passwords 


To change your password, invoke the SET PASSWORD command with 

no qualifiers. The command prompts you to provide the old password and 

then requests that you enter the new password. As a final step, the system 

asks you to enter the new password one more time for verification. If you 

fail to enter the old password correctly or do not enter the same password 

twice as the new password, the password is not changed. If you succeed in 
these three steps, there is no notification. The command terminates, and ( 
your password is changed. (Section 3.1.3.5 describes in more detail the 
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consequences of entering a new password choice that does not meet the 
minimum password length requirement.) 

When you designate a new password, the system enforces a minimum 
password length requirement, which is part of your user authorization 
record. You can enter a password choice that is equal to or longer than the 
minimum, but any shorter password choices will be rejected. 


Even if your current password has not yet expired, you can change 
your password when logging in to the system by including the 
/NEW_PASSWORD qualifier, as follows: 


WILLOW - a member of the Arboretum VAXCLUSTER 


Username: RWOODS/NEW_PASSWORD 
Password: 
Welcome to VAX/VMS Version 5.2 on node WILLOW 
Last interactive login on Tuesday, 7-NOV-1989 10:20 
Last non-interactive login on Monday, 6-NOV-1989 14:20 


Your password has expired; you must set a new password to log in 
Old password: 


New password: 


Automatically Generated Passwords 


If your system security administrator has decided that you must let 

the system generate the password for you automatically, use the DCL 
command SET PASSWORD/GENERATE to change your password. If you 
attempt to use the SET PASSWORD command without the /GENERATE 
qualifier, the system inserts it. 


Automatic password generation produces a list of password choices 
made up of random sequences of characters. The sequence resembles 
English words to make it easy to remember but is unusual enough to be 
difficult for outsiders to guess. Because system-generated passwords vary 
in length, they become even more difficult to guess. 


The following example illustrates a user requesting automatic password 
generation. The minimum password length for this user has been set to 6 
in the UAF. 


$ SET PASSWORD/GENERATE=8 
Old password: 


aps jawpha aps-jaw~pha 


oorsoult oor-soult 
guamixexab gu-a-mix-ex-ab 
impsapoc imps-a-poc 


ukchafgoy uk-chaf-goy 


Choose a password from this list or press RETURN to get a new list 
New password: 


Verification: 


$ 
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3.1.3.4 


Note: 


In the preceding example, the user requests the automatic password 
generator to provide password choices with a minimum length of eight. 
The user correctly specifies the old password and presses RETURN. The 
system responds with a list of five password choices ranging in length from 
eight to ten characters. 


To the right of each password choice is a representation of the same 
word divided into its syllables. Usually the password that is easiest to 
pronounce is easiest to remember and, therefore, the best choice. 


Next, the system reminds the user that it is possible to request a new 
list by pressing the RETURN key in response to the prompt for a new 
password. However, in this case, the user enters one of the first five 
possible passwords, followed by RETURN. The system recognizes that 
this password is one provided by the automatic password generator 

and responds with the Verification prompt. The user enters the new 
password again followed by RETURN. The system changes the password 
and responds with the DCL prompt. 


On systems where you are not required to use the password generator, 
you are strongly encouraged to use it on your own to promote the security 
of your system. A disadvantage of automatic password generation is the 
possibility that users may not remember their password choices. However, 
if you dislike all the password choices in your list or think none will be 
easy to remember, you can always request another list. 


A more serious drawback is the potential disclosure of password choices 
from the display the command produces. To protect your account, perform 
automatic password changes in private. If you perform the change on a 
video terminal, erase the display of the password choices from the screen 
after the command completes. If you use a printing terminal, properly 
dispose of all hardcopy output. If you later realize that you failed to 
protect your password in these ways, change your password immediately. 
Depending on site policy or your own judgment concerning the length of 
time your account was exposed, you might decide to notify your security 
administrator that a security breach could have occurred through your 
account. 


The password generator uses basic syllabic rules to generate 
words, but has no real knowledge of any language. As a result, it 
may unintentionally produce words that are offensive. 


There is no restriction on how many times you can change your password 
in a given period of time. There is a maximum period of time that you 
can retain the same password. This maximum period is dictated by the 
password lifetime characteristic in your UAF record set by the system 
manager. 


Password Expiration Time 

Changing passwords on a regular basis promotes system security. The 
VMS operating system includes automatic password expiration as one of 
its security features. 
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As you approach the expiration time of your password, you receive an 
advance warning message. The message first appears each time you log in 
five days prior to the expiration date. The message appears immediately 
below the new mail message and sounds the bell character on your 
terminal to attract your attention. The message indicates that your 
password is expiring, as follows: 


WARNING -- Your password expires on Thursday 19-DEC-1989 15:00 


If you fail to respond to this warning, you will receive the following 
message when you log in after your password expires: 


Your password has expired; you must set a new password to log in 


Old password: 


The system then prompts you for a new password, or, if automatic 
password generation is enabled, asks you to select a new password from 
those listed. You can abort the login by pressing CTRL/Y. You will be 
prompted to change your password on your next login attempt. 


If secondary passwords are in effect for your account (see Section 3.1.3.7) 
and both primary and secondary passwords are expired, you are prompted 
to change both passwords. If you change the primary password and press 
CTRL/Y before changing the secondary password, the login aborts and no 
password change is recorded. 


If the system manager decides not to force you to change your expired 
passwords upon logging in, you receive one final warning when you log in 
after your password expires, as follows: 


WARNING -- Your password has expired; update immediately with 
SET PASSWORD! 


At this point, if you do not change the password, or if the system fails 
before you have the opportunity to do so, you must see your system 
manager to regain access. 


Note that you cannot specify your old password as your new password. 


Minimum Password Lengths 

Your security administrator can establish a minimum length for your 
passwords by specifying a value in your UAF record. Use of longer 
passwords makes penetration more difficult. The VMS system encourages 
minimum password lengths in the range of 6 to 10 characters. You can 
choose a password as long as 31 characters, but entering long passwords is 
too cumbersome and error-prone to be practical. 


If your password choice is too short, you receive the following message: 


$SET-E-~INVPWDLEN, invalid password length - password not changed 
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3.1.3.7 


Selecting Secure Passwords 
As stated, adequate length makes passwords more secure. Avoid selecting 
passwords from a dictionary or from your native language. 


The most secure passwords include both digits and letters. For example, 
if you could choose a six-character password using letters only, you would 
find there are 300 million combinations. However, when you allow that 
same six-character password to include digits, you increase the number 
of combinations to 2 billion. Consider including digits in your password 
selection. 


Primary and Secondary Passwords 

VMS can provide an additional level of security on user accounts 

by requiring the use of secondary passwords in addition to primary 
passwords. Your security administrator decides whether to adopt this 
practice for your account at the time the account is created. When primary 
and secondary passwords are required, you must log in by first specifying 
both passwords correctly. 


In some cases one user knows both passwords and uses them to log in. 
However, the more typical case involves two users, where the primary user 
does not know the secondary password. This arrangement is designed to 
facilitate controlled logins. By requiring the presence of a supervisor or 
other key person at login time, there is added security. 


Dual passwords can also help control the actions taken after a login. For | 
certain applications, it may be desirable for another person to remain 
present while the account is in use. 


A login requiring primary and secondary passwords might appear as 
follows: 


WILLOW - a member of the Arboretum VAXCLUSTER 


Username: RWOODS 
Password: fe 
Password: 

Welcome to VAX/VMS Version 5.2 on node WILLOW 
$ 


As with a single password login, there is a limited amount of time 
allotted for the entire login. If the entry of the secondary password is 
not completed in time, the login will time out. 


Requiring a secondary password is time-consuming and inconvenient. It is 
justified only at sites with maximum security requirements. An example 
of an account that justifies dual passwords would be one that bypasses 
normal access conirois to permit emergency repair to a database. 


Primary and secondary passwords can be changed independently, but 
both are subject to the same change frequency since they share the same 
password lifetime. Minimum password length applies to both passwords. 


To change the primary password, follow the steps in Section 3.1.3.3. To 
change the secondary password, use the SET PASSWORD/SECONDARY 
command. You are prompted to specify the old secondary password and 


an 
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the new secondary password, just as in the procedure for changing the 
primary password. 


Avoiding Programs That Steal Passwords 

Beware of attempting a login from a terminal that is already turned on. 
You might be revealing your password to a program specially designed to 
steal passwords. This precaution is particularly relevant when you are 
working in a public terminal room. 


A password grabber program is a special program that displays an 
empty video screen, a screen that appears to show the system has just 
been initialized after a crash, or a screen that shows a nonexistent logout. 
When you attempt to log in, the program runs through the normal login 
sequence so you think you are entering your user name and password in a 
normal manner. However, once the program receives this key information 
and passes it on to the perpetrator, it displays a login failure. You may 
think you mistyped your password and be unaware that you have just 
revealed this vital information. 


Your security administrator will instruct you on how to eliminate this 
possibility. You may be advised to press the BREAK key before logging 
in. Pressing the BREAK key invokes the secure terminal server feature 
for the terminal, if it has been enabled by the security administrator. The 
secure server ensures that the VMS login program is the only program 
able to receive your login. 


Do not leave your terminal unattended after you log in. You may think 
the system failed and came back up again, when actually someone has 
loaded the password stealing program. Even a terminal that displays an 
apparently valid logout message may not reflect a normally logged out 
process. 


Check your last login messages routinely. The password stealing program 
cannot actually increase the login failure count, although it looks like 

a login failure to you. Be alert for login failure counts that do not 
appear following your failure, or that are one less than the number you 
experienced. If you observe this or any other anomalous failure during 

a login, change your password immediately and notify your security 
administrator. 


Protecting Your Password 

Illegal system accesses involving the use of a correct password are 
more often traced to disclosure of the password by its owner than to 
surreptitious discovery. It is vital that you do not reveal your password 
to anyone. Do not give it to friends, store it in a file, or send it in a mail 
message. 


Sometimes inadequately protected files include character strings that 
are likely to appear in conjunction with actual passwords. Browsers 
might search your files for the three-character string specific to network 
access control strings—a quotation mark followed by two colons ("::). This 
string immediately follows the username and password specification for 
network file accesses. A browser may also search your files for the string 
“password”. 
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For example, a careless user may reveal the actual password in a sentence 
like the following: 


My password is GOBBLEDYGOOK. 


Do not use the same password for accounts on different systems. An 
unauthorized user will try one password on every system where the same 
user has an account. The account that first reveals the password may 
hold little information of interest, but another account might yield more 
information or more privileges, ultimately leading to a far greater security 
breach. 


3.1.3.10 Summary of Password Guidelines 
To summarize, you can best protect your password by observing the 
following guidelines: 


e Select reasonably long passwords that cannot be easily guessed. 
Avoid using words in your national language that would appear in a 
dictionary. Consider including digits in your passwords. Alternatively, 
let the system generate passwords for you automatically. 


e Never write down your password. 


¢ Give your password to other users only under special circumstances. 
Change it immediately after the need for sharing passes. 


¢ Do not include your password in any file, including the body of an 
electronic mail message. (If anyone else reveals a password to you, 
delete the information promptly.) 


¢ Before you log in to a previously turned on terminal, invoke the secure 
terminal server feature (if enabled) by pressing the BREAK key. 


e Unless you share your password, change it every three to six months. 
Digital warns against sharing passwords. If you share your password, 
change it every month. 


e Change your password immediately if you have any reason to suspect 
it might have been discovered. Report such incidents to your security 
administrator. 


¢ Do not use the same password for your accounts on multiple systems. 


3.1.4 Account Expiration Times 


When your account is created, the security administrator may decide to 
specify a period of time after which the account will lapse (for example, if 
you will only need the account for a specific purpose for a limited time). 
At universities, student accounts are typically authorized for a single 
semester at a time. Expired accounts automatically deny logins. 


Users receive no advance warning message prior to the expiration date, 
so it is important to know in advance what your account duration will be. 
The account expiration resides in the UAF record, which can be accessed 
and displayed only through the use of the VMS Authorize Utility by 
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security administrator. 


When your account expires, you receive an authorization failure message 
at your next attempted login. If you need an extension, follow the 
procedures defined at your site. 


Causes of Login Failures 
Table 3—2 lists possible causes for login failure. 


Table 3-2 Causes of Login Failure 


Login Failure 


No response from the terminal 


No response from any terminal 


No response from terminal to your entry of 
system password 


Message: User authorization failure 


Message: Not authorized to log in from this 
source 


Message: Not authorized to log in at this 
time 


Message: User authorization failure (and no 
known user failure occurred) 


Cause 


Attempting to use a defective terminal, or the terminal requires a 
system password. 


Attempting to log in when the system is down. 
The system password changed and you were not notified. 


Mistyping the user name or password. 
Attempting to use an expired account. 
Attempting to use an expired password. 


The attempted class of login (LOCAL, DIALUP, REMOTE, 
INTERACTIVE, BATCH, or NETWORK) is prohibited. 


The day of the week or hours of the day are not permitted for you 
for this class of login. 


An apparent break-in has been attempted at the terminal using 
your user name, and the system has temporarily disabled all logins 
at that terminal by your user name. 


The following sections describe login failures. 


3.1.5.1 


System Password Failures 


You cannot log in if the terminal you attempt to use requires a system 
password and you are unaware of the requirement. As Section 3.1.3.1 
explains, some systems require that a system password be entered from 
a particular terminal before anyone can log in at the terminal. (This is 
an option the security administrator may choose to implement.) There is 
no warning message or response, so the system appears to be down. All 
attempts at logging in will fail until the system password is entered. If 
you suspect that this is the problem, try logging in at another terminal. 


If you have been directed to use a terminal that requires a system 
password and know the password, perform the steps described in 
Section 3.1.3.1. If your attempts fail, it is possible that the system 
password has been changed. Move to a different terminal that does 
not require a system password or request the new system password. 
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3.1.5.2 


3.1.5.3 


3.1.5.4 


3.1.5.5 


Login Class Restrictions 

If you attempt a class of login that is prohibited in your UAF record, 
your login will fail. For example, your security administrator may have 
restricted you from logging in over the network. If you attempt a network 
login, you receive a message telling you that you are not authorized to log 
in from this source. 


Your security administrator can restrict your logins to include or 
exclude any of the following classes (discussed in Section 3.1.1): 
LOCAL, REMOTE, DIALUP, BATCH, or NETWORK. The general name 
INTERACTIVE is useful to include or exclude all three of the classes 
LOCAL, REMOTE, and DIALUP using one expression. 


Shift Restrictions 

Another cause of login difficulty is failure to observe your shift restrictions. 
The security administrator can restrict your logins to certain times of 

the day and certain days of the week. These restrictions are imposed 

on classes of logins. The security administrator may apply the same 
work-time restrictions to all classes of logins or choose to place different 
restrictions on different login classes. If you attempt a login during a time 
prohibited for that login class, your login fails, and you are notified that 
you are not authorized to log in at this time. 


When shift restrictions apply to batch jobs, jobs you submit that are 
scheduled to run outside your permitted work times will not be run. 
The system does not automatically resubmit such jobs during your next 
available permitted work time. Similarly, if you have initiated any kind 
of job and attempt to run it beyond your permitted time periods, the job 
controller will abort the uncompleted job when the end of your allocated 
work shift is reached. This job termination behavior applies to all jobs. 


Dialup Login Failures 

Your security administrator can control the number of opportunites you 
are given to enter a correct password during a dialup login before the 
connection is automatically broken. 


If your login fails and you have attempts remaining, press RETURN and 
try again. You may do this until you succeed or reach the limit. If the 
connection is lost, you can redial the access line and start again. 


The typical reason for limiting the number of dialup login failures is to 
discourage unauthorized users attempting to learn passwords by trial 
and error. They already have the advantage of anonymity because of the 
dialup line. However, limiting the number of tries for each dialup does 
not necessarily stop this kind of break-in attempt. It only requires the 
would-be perpetrator to redial and start another login. 


Break-In Evasion Has Been Activated 

If anyone has made a number of failed attempts to log in at the same 
terminal with your user name, the system may respond as though a break- 
in attempt is in progress. That is, the system concludes that someone is 
attempting to gain illegal access to the system using your user name. Asa 
result, the system has disabled even your valid logins on that terminal for 
a certain period of time to frustrate the would-be perpetrator. 
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At the discretion of your security administrator, break-in evasion 
measures may be in effect for all users of the system. The security 
administrator controls how many password attempts are allowed over 
what period of time. Once break-in evasion tactics are triggered, you will 
be unable to log in to the terminal—even with your correct password— 
during a defined interval. Your security administrator can tell you how 
long you must wait before reattempting the login, or you can move to 
another terminal to attempt a login. 


If you suspect that break-in evasion is preventing your login, and you have 
not personally experienced any login failures, you should immediately 
contact your security administrator. Together you should attempt another 
login, checking the message that reveals the number of login failures since 
the last login, to confirm or deny your suspicion of break in attempts. (If 
your system does not normally display the login message, your security 
administrator can use the VMS Authorize Utility to examine the data in 
your UAF.) With prompt action, your security administrator may locate 
someone attempting logins at another terminal. 


3.2 Network Security Considerations for Users 


This section describes several ways to help make network access more 
secure. Topics described are access control strings in file specifications 
and command procedures, proxy logins, and proper use of the VMS Mail 
Utility. 


3.2.1. Network Access Control Strings 


Network access control strings are designed to be included in the file 
specifications of DCL commands working across the DECnet-VAX network. 
They permit a user on a local node to request an operation using a file on 
a remote node. An access control string consists of the user name for the 
remote account and the user’s password enclosed in parentheses, as shown 
in the following example: 


NODE"username password"::disk:[directory]file.typ 


Because access control strings include sufficient information to allow 
someone to break in to the remote account, they create serious security 
exposure. 


To protect access control string information, avoid revealing the 
information on either hardcopy or video terminals. Do not place 
networking commands in command procedures where they would be 
likely targets for discovery. The syntax that requires the user name 

and password to be placed within quotation marks and followed by two 
colons makes searches for passwords in insufficiently protected files easy. 
A password usually precedes the three-character access control string 
terminator ("::). If you must put networking commands that include access 
control strings in your command procedures, provide these files with 
optimum file protection using the techniques described in Chapter 4. 


You might prefer to use proxy login accounts to avoid the need for access 
control strings. Section 3.2.2 explains proxy logins. 
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Proxy Logins 
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Note: 


Proxy logins allow users to access files across a network without specifying 
user name or password in an access control string. 


Before a user can enter a request initiating a proxy login, the system or 
security administrator at the remote node must create a proxy account for 
that user. Proxy accounts, like regular accounts, are created with the VMS 
Authorize Utility. However, proxy accounts also use the network proxy 
authorization file, NETPROXY.DAT, to identify which remote users are 
allowed access to proxy accounts on the system. 


The following examples illustrate the differences between a normal 
network login request and a proxy login request. In the first case, 

the user has two user accounts, one on the node BIRCH with the 
password “XYZ123ABC” and one on the node WALNUT with the password 
“A25D3255”. The user has logged into BIRCH and wants to copy the file 
BIONEWS.MEM over from the default device and directory of the account 
on the node WALNUT. The situation is diagrammed in Figure 3-1. 


Figure 3-1 File Sharing over a Network 
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BIONEWS.MEM 
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The user enters the following command: 
$ COPY WALNUT"KMAHOGANY A25D3255"::BIONEWS.MEM BIONEWS.MEM 


Notice that since the password of the KMAHOGANY account on WALNUT 
echoes, it is revealed to anyone who observes the screen. 


If you use passwords to access files across a network, remember 
to clear the screen and empty the recall buffer with the DCL 
command RECALL/ERASE when the network job is completed. 
This prevents others from viewing the previously entered 
password using the DCL commands CTRL/B or RECALL/ALL. 
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In the next exampie, the security administrator at the node 

WALNUT also maintains an account for Kay Mahogany with the 
username KMAHOGANY and the default device and directory 

of STAFFDEV:[KMAHOGANY]. However, this time the security 
administrator at WALNUT authorizes user BIRCH::KMAHOGANY to 
perform proxy logins into the WALNUT::KMAHOGANY account. As the 
owner of the account on WALNUT, Kay has a password, but she will not 
need to specify it in her access control string when she performs network 
commands from BIRCH, because the system will perform a proxy login 
into her account. To copy the file BIONEWS.MEM from the default device 
and directory of the KMAHOGANY account on WALNUT, Kay Mahogany 
enters the following COPY command: 


$ COPY WALNUT: :BIONEWS .MEM BIONEWS . MEM 


Since no access control string was provided in the network copy 
command, the VMS operating system attempts to complete the 
operation using proxy logins. If proxy access has been set up for remote 
user BIRCH::KMAHOGONY, a network proxy login is performed on 
node WALNUT granting BIRCH::KMAHOGANY proxy access to the 
KMAHOGONY account. There is no exchange of passwords. 


This is an example of a single user proxy login account; Kay is the only 
remote user allowed to access the account. However, it is also common 
practice to authorize groups of users from foreign nodes to share in the use 
of single home node accounts, as in the following example. 


The security administrator at the node WALNUT creates a general access 
account with the user name GENACCESS that permits only network 
logins. The default device and directory are STAFFDEV:[BIOSTAFF}. 
Next, the security administrator authorizes a number of remote users 
for proxy logins to this account and includes Kay Mahogany on node 
BIRCH as one of those authorized users. The owner of the general access 
account on WALNUT has a password, but none of the remote users like 
Kay Mahogany need to know it. (Again, this is deliberate, to protect the 
account.) To copy the file BIONEWS.MEM from her own directory on the 
default device accessed through the GENACCESS account on WALNUT, 
Kay Mahogany enters the following COPY command: 


$ COPY WALNUT: : [KMAHOGANY] BIONEWS .MEM BIONEWS . MEM 


Notice that this command specifies an explicit directory for node WALNUT. 
This is only necessary because the file BIONEWS.MEM resides in 
STAFFDEV:[KMAHOGANY] while STAFFDEV:[BIOSTAFF] is the default 
device and directory for the proxy login account GENAC CESS on node 
WALNUT. Note that the protection for the file BIONEWS.MEM must 
permit access to the GENACCESS account, or the example fails. 


Observe how this arrangement also succeeds in eliminating the need to 
forward the password as a string. This is the key characteristic of proxy 
logins, whether the accounts are set up for single remote users or groups 
of remote users. Had the file BIONEWS.MEM been moved to the directory 
[BIOSTAFF], the two copy commands illustrating proxy logins could have 
been identical. 
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3.2.2.1 


Thus, while proxy logins require more setup effort on the part of system 
managers, they provide more secure network access and involve much 
simpler procedures for the users. 


Multiple Proxy Accounts 

Security administrators can allow remote users access to one default 
proxy account and up to 15 other proxy accounts. If a remote user has 
access to more than one proxy account and wants to copy files over the 
network using a proxy account other than the default, the name of the 
proxy account must be specified in the access control string. For example, 
suppose remote user Kay Mahogany in the previous section has proxy 
access to the GENACCESS, PROXY2, and PROXY3 accounts and the 
default proxy account is GENACCESS. To copy the file BIONEWS.MEM 
from the default device and directory on node WALNUT using the PROXY2 
proxy account, Kay Mahogony enters the following COPY command: 


$ COPY WALNUT"PROXY2": :BIONEWS.MEM BIONEWS .MEM 


3.2.3. Using the VMS Mail Utility 


The VMS Mail Utility has default file protection to discourage mail 
tampering. However, the Mail Utility is not completely tamperproof. 


Anyone with sufficient privilege can change protection and access mail 
files. 


Therefore, use discretion both in the content of your mail messages and in 
the selection of your audience. Never reveal your password or send details 
about how to use your account. You have no control over information in a 
mail message once you have sent it. 


3.3 Logging Out of the System 


When you leave your terminal on line and your office open, you have 
effectively given away your password, your privileges, and left your files 
and those of the other members of your group unprotected. Any user can 
easily and quickly transfer all files accessible through your account. A 
malicious insider could rename and delete your files and any to which you 
have WRITE access. If you have special privileges, especially SETPRV, a 
malicious user can do major damage. 


Therefore, establish criteria for when to log out of your system. Log out 
when you leave your office even for a brief period of time. Leaving a 
terminal on line represents one of the greatest sources of inside break-ins. 


3.3.1 Logging Out from Video Terminals 
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There are several steps you may want to consider each time you log out. 
Information left on your terminal screen at logout can vary. At sites with 
medium-level security concerns, it may be important to leave nothing but 
the logout message on your screen, as follows: 
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e If your terminal is a VT100 series terminal, clear the screen by using 
the setup feature of your terminal. (Press the SET-UP key, then the 
key marked for reset (the 0 key), followed by the RETURN key.) 


¢ If your terminal is in the VT200 or VT300 series of terminals, you can 
accomplish this by pressing the SET-UP key, then selecting the item 
from the resulting menu that corresponds to CLEAR DISPLAY. 


Once the screen has cleared, and the DCL prompt returns, you can enter 
the DCL command LOGOUT. Since your screen is clear, the cursor is 
positioned at the top of the screen. The only information remaining is your 
logout command and the logout completion message, as follows: 


$ LOGOUT 
RDOGWOOD logged out at 14-AUG-1989 19:39:01.43 


At high-security sites, it is common practice to turn off your video terminal 
every time you log out because the logout message reveals a currently 
active user name. When users log out after a remote login, the name of 
the node they return to after the remote logout is also revealed. When 

a user has accessed multiple accounts remotely over the network, the 
final sequence of logout commands reveals all the nodes and the user 
names that are accessible to the user on each node, with the exception 

of the name of the furthest node reached. To those who can recognize 

the operating system from the prompt or a logout message, this will also 
reveal the operating system. 


If the system fails before you log out, there may be important information 
left on your screen. To avoid this, turn your video terminal off and then 
on. Then wait for the system initialization message or your first chance 
to reaccess the terminal concentrator. If you plan to leave the area, do 
not turn the terminal on again until you return. Observe the precautions 
described in Section 3.1.3.8 to avoid password grabbers. 


3.3.2 Logging Out from Hardcopy Terminals 


When you need to log out from a hardcopy terminal, enter the DCL 
command LOGOUT. If you have performed remote logins, you must log 
out of each node. Properly remove, file, or dispose of all hardcopy output 
that might reveal security information. Your security administrator should 
provide direction on preferred procedures. Many sites use paper shredders 
or locked receptacles for this purpose. Handle output that you plan to save 
just as carefully. 


If the system fails before you log out, dispose of the hardcopy output. Turn 
your terminal off if you will not be present when the system is initialized. 


3.3.3 Logging Out from Disconnected Processes 
To conserve system resources, perform the following steps: 


e Enter the DCL command SHOW USERS to determine if you have 
other disconnected jobs. 
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e Enter the DCL command CONNECT/CONTINUE to log out of the 
current process. Connect back through each of the associated virtual 
terminals (as noted by the terminal prefix of VTA) until you have 
reached the last existing process. 


e Enter the DCL command LOGOUT. 
If you do not perform these steps, the system automatically removes your 


disconnected processes after a certain interval. Performing these steps 
saves system resources. 


3.3.4 Logging Out from a Dialup Login 


Your security administrator may request that you always use the 
/HANGUP qualifier with your final LOGOUT command when you log out 
from a dialup login and anticipate no further immediate use of the line. 
The use of the /HANGUP qualifier on a LOGOUT command directs VMS 
to automatically break the connection to the dialup line after the logout. 
No one can take advantage of an open access line; it is necessary to know 
the access number and personally redial. This is especially important if 
the dialup line you use is in a public area or where someone might use the 
terminal after you. 


The /HANGUP qualifier will work for all terminals that have been set 
up with the HANGUP terminal characteristic. (The system manager 
specifies the HANGUP characteristic with the DCL command SET 
TERMINAL/PERMANENT/HANGUP.) 


This practice also saves resources by reducing the required number of 
dialup lines. 





3.4 Summary of Recommended User Practices 
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This chapter has presented many suggestions to help maintain a secure 
system. Although many security features are implemented by the security 
administrator as requirements for all users, there are many ways users 
can contribute to system security. The following list reviews voluntary 
security actions. Included are cross-references to parts of this chapter 
where each topic is discussed. 


e Protect your password (Section 3.1.3.10). 


¢ Check your last login messages each time you log in, and report any 
unexplained messages to your security administrator (Section 3.1.2.4). 


¢ Lock up and log out when you leave your terminal and area 
(Section 3.3). 


e Use the /HANGUP qualifier on your final LOGOUT from a dialup line 
(Section 3.3.4). 


e Properly dispose of hardcopy output from your terminal (Section 3.3.2). 
¢ Turn off your video terminal to erase revealing displays (Section 3.3.1). 


¢ Use proxy logins when possible (Section 3.1.1.4). 
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Object Protection Features 


Object protection mechanisms are extremely important tools for enhancing 
system security. This chapter explains these protection mechanisms and 
their use. 


The VMS operating system offers two primary protection mechanisms. 
The first, standard UIC-based protection, is based on the user 
identification code (UIC) and is applied to all objects. It controls access 
to files according to the user categories SYSTEM, OWNER, GROUP, and 
WORLD. 


The second protection mechanism uses access control lists (ACLs), 
which employ a more refined level of protection than that available with 
UIC-based protection. ACLs can be used to grant or deny file access to 
individual users or groups of users, independent of the UIC. 


ACLs are important protection tools available to all VMS users and are 
generally used at sites with medium to high security requirements. ACLs 
are also prevalent in environments with complex patterns of file sharing. 
As security requirements increase, so does the use of ACLs. 





How the System Determines Access 


There is an interaction between ACLs, the UIC-based protection code, and 
user privileges that determines the outcome every time a user requests 
access to an object. This section introduces the order in which VMS 
evaluates each of these components. 


The VMS operating system performs the following steps to determine if a 
user is allowed access to a particular object: 


1 If an object has an associated ACL, the system uses that ACL to 
determine whether the user should gain access to the object. If the 
ACL grants the requested access to the user, access is given and all 
further testing stops. If the ACL denies access, the system uses the 
SYSTEM and OWNER fields of the UIC-based protection to determine 
if the user is allowed access. If the ACL does not explicitly grant 
or deny the user access, the system uses UIC-based protection to 
determine access. 


2 Ifan object does not have an associated ACL, the system uses 
UIC-based protection to determine access. (See Section 4.2.3.) 


3 The GRPPRV, SYSPRV, READALL, and BYPASS privileges amplify 
the privilege holder’s access to objects under certain circumstances. 
(See Section 4.2.5.) 
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Following is a user-access summary: 
e ACLs are always evaluated first. 


¢ When an ACL fails to specifically grant access, UIC-based protection is 
checked. 


e When an ACL specifically denies access, the user can still acquire 
access by being a member of the SYSTEM or OWNER categories and 
thereby eligible for access through them, or by possessing privileges. 


¢ Users with certain system privileges may be entitled to access 
regardless of the protection offered by the ACLs or the UIC protection 
code. 


4.2 Standard UIC-Based Protection 


When security administrators create accounts, they perform two actions 
that affect the UIC-based protection: 


e They establish each account with a standard default protection code 
for all files the user creates in the initial top-level directory. 


e They assign each user membership in a group. 


Your default protection code and group assignment may be sufficient 

for all files that you work with. Use the DCL command SET 
PROTECTION if you need to change the protection on certain files or 
SET PROTECTION/DEFAULT if you need to change the default protection 
for all new files that you create. Section 4.2.4 describes the syntax of the 
SET PROTECTION command. 


Each user of the system has a UIC defined in the system user 
authorization file (UAF). Each system object (such as a file) also has 

an associated UIC, defined to be the UIC of its owner, and a protection 
code that defines who is allowed what type of access. The relationship 
between the UIC of the user and the UIC of the object controls access to 
the object. 


4.2.1 UlCs and Protection 


4-2 


UIC-based protection is determined by the UIC of the owner of the object 
and the protection code defined for the object. (Section 4.2.3 defines how 
the VMS operating system groups users according to UIC. ) 


UIC-based protection controls access to objects such as files, directories, 
and volumes. A volume refers to a mass storage medium mounted on 

a device. For example, disk packs and reels of magnetic tape are called 
volumes when mounted on disk and magnetic tape drives. For disk 
volumes, the system provides protection at the file, directory, and volume 
levels. For magnetic tape volumes, the system provides protection only at 
the volume level. 


4.2.2 


Specifying UICs 


4.2.2.1 


4.2.2.2 
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Thus, ii Addition to protecting the files OM Mounted disk volumes, the 
VMS system provides overall volume protection for disks and magnetic 
tapes. This volume protection is coded into the home block of the disk 
or magnetic tape. (The home block is the section of the index file that 
contains access and identification information for the volume.) For more 
information about setting volume protection characteristics for disks 
and magnetic tapes, see the Guide to Maintaining a VMS System and 
the descriptions of the DCL commands INITIALIZE, MOUNT, and SET 
VOLUME in the VMS DCL Dictionary. 


VMS also provides protection for record-oriented devices such as terminals, 
line printers, mailboxes, and special-purpose devices. See the description 
of the SET PROTECTION/DEVICE command in the VMS DCL Dictionary 
for information on how to apply protection to record-oriented devices. 


The system manager assigns a UIC to each user with the VMS Authorize 
Utility. A UIC has two formats: numeric and alphanumeric. When a DCL 
command requires a UIC specification, you can use either format to refer 
to a user. 


For example, the following UIC specifications could all be valid for the 
user JONES: 


[360,031] 
[JONES] 
[GROUP1 JONES] 


Numeric Format UICs 
A UIC in numeric format contains a group number and a member number 
in the following format: 


[group, member] 


The brackets are required in the UIC specification. The group number is 
an octal number in the range of 1 through 37776; the member number is 
an octal number in the range of 0 through 177776. You can omit leading 
zeros when you are specifying group and member numbers. 


Alphanumeric Format UICs 
A UIC in alphanumeric format consists of a member name and, optionally, 
a group name in the following format: 


[member] 
[group, member] 


The brackets are required in the UIC specification. The group and member 
names can each contain up to 31 alphanumeric characters and must 
contain at least one alphabetic character. The names can include the 
characters A through Z, dollar signs ($), underscores (_), and the numbers 
0 through 9. 
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4.2.2.3 UIC Translation and Storage 
Regardless of the format you use, the system translates a UIC to a 
32-bit value that represents a group number and a member number; the 
high-order 16 bits contain the group number, and the low-order 16 bits 
contain the member number. When translating an alphanumeric UIC 
such as [J_JONES], VMS equates the member part of the alphanumeric 
UIC to both the group and member parts of a numeric UIC. The resulting 
32-bit numeric UIC is kept in the system rights database, which is a 
file containing information pertaining to the access rights and attributes 
associated with identifiers and the holders of those identifiers. 


This method of storing alphanumeric UICs dictates that member names 
must be unique, and that no member can participate in more than one 
group. That is, each member name must be unique for each user on the 
system. For example, you could not have the two UICs [GROUP1,JONES] 
and [GROUP2,JONES] on the same system because the member JONES 
can have only one associated numeric UIC. 


A group name is associated with the group portion of a UIC. When the 
system translates an alphanumeric UIC that includes both a group and a 
member name, the system obtains the longword integer associated with 
the member and checks the group name against the member. 


4.2.3. How UIC-Based Protection Controls Access 


As indicated in Section 4.1, when a user attempts to gain access to an 
object (such as a file or volume), in almost all cases the system checks the 
UIC-based protection code. This involves comparing the user’s UIC to the 
owner’s UIC of the object. (An exception occurs when there is an ACL on 
the object that grants access immediately to the requesting user.) Users 
attempting access to system objects (such as files) always fall into one or 
more of the following categories: 


SYSTEM One of the following: 
All users who have system privilege (SYSPRV). 


oo 


Users with low group numbers, usually from 1 through 10 (octal). The 
exact range of system group numbers is determined by the system 
manager (with the SYSGEN parameter MAXSYSGROUP) when 

the system is generated and may range as high as 37776 (octal). 
These group numbers are generally for system managers, security 
administrators, system programmers, and operators. 


Users with the user privilege GRPPRV whose UIC group matches the 
group of the object’s owner. 


For files on disk volumes, users whose UIC matches the owner UIC of 
the volume on which the file is located. 


OWNER The user with the same UIC as the user who created and therefore 
owns the object. 


GROUP All users, including the owner, who have the same group number in 
their UICs as the object’s owner. 
WORLD All users, including those in the first three categories. [ 
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Figure 4-1 Illustrating User Categories with a UIC of [100,100] 
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Through the protection code, each category of user can be allowed or 
denied any of the following types of access: 


¢ READ 

¢ WRITE 

¢ EXECUTE 
¢ DELETE 


CONTROL access is a fifth type of access that can be specified in an ACL 
and is automatically granted to certain user categories when UIC-based 
protection is evaluated. CONTROL access grants the accessor dail the 
privileges of the object’s actual owner. For example, the user who acquires 
CONTROL access can change the protection and file characteristics, just 
as the owner could. Thus, users in the SYSTEM or OWNER categories 
always have CONTROL access, while users in the GROUP or WORLD 
categories never receive CONTROL access. The previous list omits 
CONTROL access since it is never specified in the standard UIC-based 
protection code. 


The significance conveyed by the access types READ, WRITE, EXECUTE, 
DELETE, and CONTROL varies depending on the situation where they 
apply. For example, EXECUTE access permits different operations 
depending on whether it is granted for general file access, directory file 
access, or volume access. The sections that describe each of these objects 
also detail the abilities that each access type allows. 
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The protection code describes the categories of users who have access to 
an object and the type of access that each category has. For example, the 
protection code in the next example specifies that users in the SYSTEM 
and OWNER categories have READ, WRITE, EXECUTE, and DELETE 
access: 


SYSTEM:RWED, OWNER:RWED, GROUP:RE, WORLD:RE 


In this example, users in the GROUP and WORLD categories have only 
READ and EXECUTE access. 


Protection Code Syntax 


The following syntax rules apply to protection codes: 


When you specify a protection code, you must abbreviate access types 
to one character: R, W, E, or D. User categories can be entered in full 
or truncated to any number of characters. Separate each user category 
from its access types with a colon. If you specify more than one user 
category, separate the categories with commas, and enclose the entire 
code in parentheses. The following DCL command sets the protection 
code: 


$ SET PROTECTION=(S:RWED,OWN:RWED,GROUP:R,W:R) DATAFILE.DAT 


You can specify user categories and access types in any order. If you 
omit an access type for a user category, that category of user is denied 
that type of access. If you want to deny all access to a user category, 
specify the user category, but do not list any access types. Omit the 
colon after the user category when you are denying access to a category 
of users. For example, the following DCL command sets the protection 
code to deny WRITE and DELETE access to the GROUP category and 
denies all access to the WORLD category: 


$ SET PROTECTION=(S:RWED,O:RWED,G:RE,W) DATAFILE.DAT 


When you omit a user category from a protection code, the current 
access allowed that category of user remains unchanged. For example, 
assume the protection code in the immediately preceding example is 
in effect. The following DCL command resets the protection on the 
file DATAFILE.DAT so that the SYSTEM and OWNER categories of 
users can no longer DELETE the file, but the GROUP category will 
still retain READ and EXECUTE access. The WORLD category will 
still be denied any access: 


$ SET PROTECTION=(S:RWE,O:RWE) DATAFILE.DAT 


When you set the protection for magnetic tape volumes, the SYSTEM 
and OWNER categories always have access, regardless of the 
specification in the protection code. 
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How Privileges Affect Protection 


The VMS system features privileges that system and security managers 
can assign to users when they create or modify user accounts. The 
following four system privileges affect user access, regardless of the access 
dictated by either an ACL for the object or the access granted through 
matching the user’s category in the protection code: 


e SYSPRV 

¢ GRPPRV 

e READALL 
¢ BYPASS 


The following list explains these privileges: 


SYSPRV A user with SYSPRV privilege receives the access accorded to users 
in the SYSTEM category. 


GRPPRV A user with GRPPRV privilege whose UIC group matches the group of 
the owner of the object receives the same access accorded to users 
in the SYSTEM category. Thus, the user with GRPPRV privilege is 
able to manage a group’s files. 

BYPASS A user with BYPASS privilege receives all types of access to the 
object, regardless of its protection. 


READALL A user with READALL privilege receives READ and CONTROL access 
to the object, even if that access is denied by the ACL or UIC-based 
protection. In addition, the user may receive any other access granted 
through the protection code. 


When you define ACLs or UIC protection codes for your objects, remember 
that users with amplified privileges are entitled to special access to objects 
throughout the system. For example, there is no way to stop a user with 
the BYPASS privilege from accessing your files. Protection of your objects 
depends on the judgment of your security administrator in granting these 
privileges. 


How the System Interprets a Protection Code 


To determine access to an object (such as a file or a device), the system 
uses the object’s protection code for each user category. The system checks 
user categories in the following sequence: 


1 OWNER 
2 WORLD 
3 GROUP 
4 SYSTEM 


You can access a system object as soon as the system finds a user category 
into which you fit that gives you the access you have requested. 
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4.2.7.1 


4.2.7.2 


Note: 


To deny access to a user category, you must deny access to all the 
outermost categories. For example, the following protection code appears 
to deny DELETE access to the OWNER category: 


SYSTEM:RWED, OWNER:RW, GROUP:RW, WORLD:RWED 


However, the owner of the file can still delete the file. Although DELETE 
access is denied through the OWNER category, the system continues 
checking the remaining categories for permission to grant access. Because 
the owner also fits in the WORLD category (which applies to all users) 
and the WORLD category is permitted DELETE access, the system grants 
DELETE access to the owner. 


How the System Interprets Object Access Types 


Depending on the object, VMS applies different meanings to the access 
types READ, WRITE, EXECUTE, DELETE, and CONTROL. This section 
describes several objects and the different interpretations of access types 
for each. 


Disk Files 
Each file on a disk has its own protection code. When applied to files, 
access types have the following meanings: 


READ The right to examine (read), print, or copy the file 

WRITE The right to write to or modify the file 

EXECUTE _ The right to execute a file that contains an executable program image 
or DCL command procedure 

DELETE The right to delete the file 

CONTROL _ The right to change the protection and file characteristics of the file 


Note that READ access also implies EXECUTE access. WRITE access 
permits a user to change the contents of a file, even though the file cannot 
be deleted from the directory without DELETE access. 


To open a file for writing, you must have both READ and WRITE 
access. The VMS operating system does not support write-only 
files. 


Directory Files 

Each directory file (easily recognized as a file with the file type DIR) has 
a protection associated with it. This directory protection can override the 
protection of individual files in the directory. When applied to directories, 
access types have the following meanings: 


READ The right to examine (read) or list the directory file 

WRITE The right to write to or modify the directory file 

EXECUTE _ The right to look up files in the directory if you explicitly specify the file 
name 


DELETE The right to delete the directory file 
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CONTROL _ The right to change the protection and fiie characierisiics of ine directory 
file 


Note that READ access implies EXECUTE access. 


If you have READ access to a directory file, you can display the contents 
of the directory file with the DCL command DIRECTORY. You can use 
wildcards (explicitly or implicitly). For example, if you have READ access 
to the directory [MALCOLM], you can obtain a listing of all files contained 
in the [MALCOLM] directory by entering the following command: 


$ DIRECTORY [MALCOLM] *.*;* 


You can access any file stored in the directory unless the protection on that 
file denies you access. However, if a directory denies you READ access, 
you cannot look up or access even those files in the directory that permit 
access to users in your group. The Files-11 structure (the file structure 
used by the VMS operating system) is not hierarchical, and it is possible to 
write a program to access files without using the directory in which they 
are listed. Therefore, to guarantee protection, protect individual files as 
well as directories. 


WRITE access allows you to write to the directory file. You must have 
both READ and WRITE access to a directory in order to create files in that 
directory, to rename files, or to perform any file operation that involves 
changes to the directory file. 


EXECUTE access allows you to use the DIRECTORY command to look up 
files that you can identify by name. In addition, you can access files in the 
directory not protected from users in your category as long as you do not 
perform an operation that modifies the directory file. You cannot list all 
the entries in the directory using wildcards. 


In the next example, if you have EXECUTE access to the [MALCOLM] 
directory and you enter a DIRECTORY command without naming any 
files, the system does not list the files and responds with the following 
error message: 


%DIRECT-E-OPENIN, error opening disk:[MALCOLM]*.*;* as input 
-RMS-E-PRV, insufficient privilege or file protection violation 


However, if you know that the file DATAFILE.DAT exists in the 
[MALCOLM] directory, you can enter a more specific command, as in 
the following example: 


$ DIRECTORY [MALCOLM] DATAFILE.DAT;0 


The system lists the corresponding directory information. EXECUTE 
access provides some, but not all, of the operations that READ provides. 


DELETE access allows you to delete a directory file. You must delete all 
files from a directory before you can delete the directory file. When you 
create a directory file with the CREATE/DIRECTORY command, you do 
not, by default, receive DELETE access. If you want to delete a directory 
file, you must use the SET PROTECTION command to explicitly assign 
DELETE access to the OWNER category, as follows: 


§ SET PROTECTION=OWNER:D TEST.DIR;1 
§ DELETE TEST.DIR;1 
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4.2.7.3 


4.2.7.4 


4.2.7.5 


4.2.7.6 


Note: 


Volumes 

When applied to volumes, access types have the following meanings: 
READ The right to examine, print, or copy files on a volume 

WRITE The right to modify or to write existing files on a volume 


EXECUTE _ The right to create files on the volume and to write into them 
DELETE The right to delete files on the volume 
CONTROL __ The right to change the protection and ownership of the volume 


Note that READ access on volumes limits the access to read only. 


EXECUTE and DELETE access are not valid for magnetic tapes. 
Granting a category of users WRITE access to a tape volume 
automatically permits them to have READ access to the volume. 


Global Sections 

When applied to global sections, access types have the following meanings: 
READ The right to map the section for read access 

WRITE The right to map the section for write access 


EXECUTE _ The right to map the section for execute access (available only to 
privileged software) 


CONTROL The right to change the access control list (applies only to PFN and page 
file global sections) 


Devices 
When applied to shareable devices, access types have the following 
meanings: 


READ The right to issue read requests to the device 

WRITE The right to issue write requests to the device 

LOGICAL I/O The right to issue logical /O requests to the device 

PHYSICAL I/O The right to issue physical I/O requests to the device 

CONTROL The right to change the device ACL ( 


For nonshareable devices, such as terminals, each category of user can 
either be allowed or denied access to allocate and assign channels to the 
device. The READ category controls whether a user can allocate and 
assign channels to the device. All other categories are not relevant for 
nonshareable devices. 


Logical Name Tables 

When applied to logical name tables, access types have the following 
meanings: 

READ The right to look up logical names in the table 

WRITE The right to create and delete logical names in the table 

DELETE The right to delete the table 

CONTROL The right to change the logical name table ACL 


Mi 
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4.2.7.7 Queues 
Operations that apply to a queue or to specific jobs in a queue are 
controlled by UIC-based protection in the same way access to other system 
objects is controlled. The ability to control queue operations through 
UIC-based protection allows you to restrict the types of jobs and users for 
a particular queue. 


When you initialize a queue, the queue is assigned a default owner UIC of 
[SYSTEM] and the following default protection mask: 


SYSTEM:EXECUTE,OWNER:DELETE,GROUP:READ,WORLD:WRITE 


Jobs are assigned an owner UIC equal to the UIC of the process that 
submitted the job. Each operation performed on a queue or a job ina 
queue is checked against the owner UIC, protection of the queue and the 
job, and the privileges of the requestor. 


Operations that apply to jobs are checked against the READ and DELETE 
protection specified for the queue and the owner UIC of the job. In general, 
READ access to a job allows a user to see the attributes of a job, and 
DELETE access allows the user to delete the job. 


Operations that apply to queues are checked against the WRITE and 
EXECUTE protection specified for the queue and the owner UIC of the 
queue. A user with WRITE access to a queue can submit jobs to that 
queue. A user with EXECUTE access to a queue can act as the operator 
for that queue with the ability to affect any jobs in the queue. Users with 
operator (OPER) privilege have EXECUTE access to all queues. OPER 
privilege also enables users to establish queues and affect accounting. 


The following table summarizes the privileges required for various queue 
operations: 


Command 


START/QUEUE/MANAGER 
STOP/QUEUE/MANAGER 
DEFINE/CHARACTERISTIC 
DEFINE/FORM 
DELETE/CHARACTERISTIC 
DELETE/FORM 
DELETE/QUEUE 
INITIALIZE/QUEUE 

SHOW QUEUE 
SYNCHRONIZE 

PRINT 

SUBMIT 

ASSIGN/MERGE 
ASSIGN/QUEUE 
DEASSIGN/QUEUE 


Privilege Required 


OPER and SYSNAM 

OPER and SYSNAM 

OPER 

OPER 

OPER 

OPER 

OPER 

OPER 

OPER, EXECUTE access to the queue, or READ access to the job 
WRITE access to the queue and READ access to the job 
WRITE access to the queue and READ access to the file 
WRITE access to the queue and READ access to the file 
OPER or EXECUTE access to the queue 


- OPER or EXECUTE access to the queue 


OPER or EXECUTE access to the queue 
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Command 


SET QUEUE 
START/QUEUE 


_STOP/QUEUE 
STOP/QUEUE/NEXT 
STOP/QUEUE/RESET 


DELETE/ENTRY 


SET QUEUE/ENTRY 
STOP/QUEUE/ABORT 
SET RESTART_VALUE 


Privilege Required 


OPER or EXECUTE access to the queue 

OPER or EXECUTE access to the queue 

OPER or EXECUTE access to the queue 

OPER or EXECUTE access to the queue 

OPER or EXECUTE access to the queue 

OPER, EXECUTE access to the queue, or DELETE access to the job 
OPER, EXECUTE access to the queue, or DELETE access to the job 
OPER, EXECUTE access to the queue, or DELETE access to the job 
No privilege required 


Establishing and Changing UIC-Based Protection 
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4.2.8.1 


This section describes how UIC-based protection is initially established for 
volumes, files, global sections, devices, logical name tables, and queues. It 
also describes how you can change the protection of volumes, files, devices, 
and queues. 


Volume Protection 

VMS determines the UIC-based volume protection when a volume is 
mounted; the default can be taken from the protection recorded on the 
volume, or it can be explicitly specified. (See the descriptions of the 
INITIALIZE and MOUNT commands in the Guide to Maintaining a 
VMS System for more information on setting volume protection when you 
mount a volume.) To change the protection of a disk volume, use the SET 
VOLUME command. 


Volume protection for magnetic tape volumes differs significantly from 
disk volume protection. The protection applied to a magnetic tape volume 
applies equally to all files on the volume. VMS applies only READ and 
WRITE access restrictions to magnetic tapes; EXECUTE and DELETE 
access are meaningless. Users in the SYSTEM and OWNER category 

are always given both READ and WRITE access, regardless of what is 
specified in the protection code. Protection must be explicitly specified 
when a volume is initialized, or all users will have READ and WRITE 
access. If you give WRITE access to the GROUP or WORLD categories, 
READ access is also allowed. For magnetic tapes, users in the SYSTEM 
and OWNER categories are always given logical and physical I/O access in 
addition to READ and WRITE access, regardless of what is specified in the 
protection code. 


To change file protection on a magnetic tape, you must reinitialize the 
tape. 


~ 


bp, 8 


4.2.8.2 


4.2.8.3 
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Directory Protection 

UIC-based directory file protection pertains only to disk directories and is 
normally established when the directory is created. At directory creation 
time, you can specify either a protection code with the /PROTECTION 
qualifier to the DCL command CREATE/DIRECTORY or permit the 
protection to default to that of the next higher directory in the tree. If the 
directory is a top-level directory, the protection is taken from the master 
file directory (MFD). For example, to create the top-level directory file 
MONROE.DIR with open access to all but the WORLD category of users, 
the security administrator would enter the following command: 


$ CREATE/DIRECTORY/PROTECTION=(S:RWED,O:RWED,G:RWED,W) ~ 
_§ BOTANYDISK: [MONROE] 


Any user with CONTROL access can change the protection on the 
directory with the DCL command SET PROTECTION. For example, the 
following command changes the protection for the directory [MONROE] by 
removing access for the GROUP category: 


$ SET PROTECTION=(S:RWED,O:RWED,G,W) MONROE.DIR 


File Protection 

When you create a new file, the file obtains a UIC-based protection code 
either from the default protection provided by the directory it will reside 
in or from the default protection of your process. (These defaults are 
described in Section 4.5.) 


A newly created version of an existing file receives the protection code of 
the previous version of the file. You can specify a protection code when you 
create a copy of a file. For example, you can use the /PROTECTION 
qualifier to define the protection for a file you create with the DCL 
command COPY, as follows: 


$ COPY USE1: [PAYDATA]PAYROLL.DAT PAYSORT.DAT - 
_§$ /PROTECTION= (SYSTEM: RW, OWNER: RWED, GROUP : RW, WORLD) 


The previous COPY command copies a file from the device USE1 to your 
default disk directory. The protection code defines the protection for the 
newly created file PAYSORT-.DAT, as follows: 


e Users with system UICs (those in the SYSTEM category) can read and 
write to the file. 


e You (in the OWNER category) have all types of access. 


e Other users in your group (those in the GROUP category) can read 
and write to the file. 


¢ All other users (those in the WORLD category) are permitted no 
access. 


You can also change the protection for one of your existing files with the 
SET PROTECTION command, as follows: 


$ SET PROTECTION=(SYSTEM:RWE, OWNER: RWED,GROUP:RE,WORLD) - 
_$ PAYSORT.EXE 
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4.2.8.4 


4.2.8.5 


4.2.8.6 


4.2.8.7 


Global Section Protection 

UIC-based protection on global sections, except those backed by disk files, 
must be reestablished every time the section is created. If the global 
section is backed by a disk file, the section protection is derived from 
the disk file so that changing the file protection changes the section 
protection. For page frame number (PFN) and page file global sections, 
set the protection in the $CRMPSC system service call that creates the 
section; you cannot change the protection after the section is created. 


Device Protection 
UIC-based protection on devices must be reestablished every time the 
system is booted. Set device protection with the following command: 


$ SET PROTECTION=(code) /DEVICE device-name[:] 


Logical Name Table Protection 

UIC-based protection on logical name tables must be reestablished every 
time the logical name table is created. Set the protection with the 
protection argument to the $CRELNT system service call or with the 
following command: 


$ CREATE/NAME TABLE/PROTECTION=(code) table-name 

You cannot change the protection on an existing logical name table. 
Queue Protection 

Set UIC-based protection on a queue with the /PROTECTION qualifier 
to the INITIALIZE/QUEUE, START/QUEUE, or SET QUEUE command. 


For example, use the following command to change the protection on the 
FAST$BATCH queue: 


$ SET QUEUE/PROTECTION=(code) FASTS$BATCH 


4.3 Access Control Lists (ACL) 
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An alternate means of protection offered with the VMS operating system 
is the access control list (ACL). ACLs consist of access control list entries 
(ACEs) that grant or deny access to a particular system object. Each ACE 
specifies a user or group of users and the type of access permitted. ACLs 
define access more precisely than the default UIC-based protection scheme 
by allowing you to create groups of users independent of the users’ UICs. 


ACLs can be placed on the following types of objects: 
e Devices 

¢ Files Gincluding directory files) 

¢ Group global sections 

e System global sections 

e Logical name tables 


¢ Queues 
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VMS provides a file called a rights database that contains a list of special 
names called identifiers as well as a list of the users specified as holders 
of identifiers. The security administrator uses the VMS Authorize Utility 
to maintain the rights database, adding and removing identifiers and 
holders of identifiers as necessary. By allowing groups of users to hold 
identifiers, the manager has created a group designation that differs from 
the one used with the user’s UIC. This alternative method of grouping is 
more finely tailored to the uses the holders of the identifier are expected to 
make of the objects. This method also permits each user to be a member 
of multiple overlapping groups. 


Each time you log in, the system creates a process rights list for you 
containing a list of the identifiers in the rights database associated with 
your process. When you attempt to access objects protected with ACLs, 
the system searches the object’s ACL for an identifier granting access that 
matches one of the identifiers in your process rights list. 


The following sections describe the relationship between ACLs and 
identifiers in more detail. 


4.3.1 ACLs, Identifiers, and the Reference Monitor 


The reference monitor model specifies an authorization database, which 
describes all access authorizations in the system for all subjects and all 
objects. This database is often represented as an access matrix, listing 
subjects on one axis and objects on the other. Each crosspoint in the 
matrix thus represents the access that one subject has to one object. 


Figure 4—2 provides an example of an access matrix: 


Figure 4-2 Example of an Access Matrix 
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In this access matrix, an asterisk (*) is used to denote that the subject has 
access to that object (different types of access, such as READ and WRITE, 
are omitted from this example for simplicity). Thus, subjects B, C, and D 
all have access to objects W, X, and Y. In addition, subject A has access to 
objects W and Z, subject D to object V, and subject E to object V. 


Breaking up the access matrix by rows yields a capability-based system, 
in which each subject carries a list of the objects that it can access. Thus, 
a capability representation of this access matrix would appear as follows: 


sais 
bs 
,X 
W, 


=: 
x<< 


as 


MmOUOW>D 
<<s 


It is also possible to break up the access matrix by columns, listing 

for each object the subjects that have access to it. This results in an 
authority-based system, or access control lists. The access control list 
representation appears as follows: 
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The access control list and identifier system that VMS implements 
combines properties of both the capability- and authority-based systems. 
The result is an extremely powerful and flexible system capable of 
representing complex access matrixes in a compact and convenient 
manner. Consider what happens to the previous example of an access 
matrix when some of the crosspoints have labels, as in Figure 4-3. 


Figure 4-3 Previous Matrix with Labeled Crosspoints 


Objects: 
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Some iabeied crosspoinis can be grouped and ireaied as a singie entity. 
Thus, the points that are labeled Q represent the access that subjects B, 
C, and D have to objects W, X, and Y. All the Q points can be considered as 
a single area of interest. VMS provides the concept of identifiers to take 
practical advantage of this grouping of areas of interest. 


You can define identifiers to represent the two groups of access, P and Q, 
in the example matrix. Note that two of the crosspoints in the example 
remain unlabeled. VMS identifiers can also represent individual subjects, 
and thus allow the traditional access control list facility. 


To represent the access matrix, VMS uses two structures, one for each 
dimension. The system rights database represents the rows of the access 
matrix, and thus corresponds to the capability model. For this example, 
you would need the following rights database: 


B: Q 

Cc: Q 

D: P,Q 

E: OP 
Access control lists on the protected objects represent the columns of the 
access matrix. For this example, you would need the following access 
control lists: 


<xxXSS 
OO>p> 
O 


Z: A 
Note that the VMS structures required to represent the access matrix 
are simpler than either the traditional capability or authority mode] and 
require fewer terms in total. In the example, the difference is slight. 


However, complexity of the access matrix increases with the square of its 
size. 


4.3.2 Creating and Maintaining ACLs 


Use the VMS ACL Editor to create and edit an ACL on a specific object. 
You can also use the DCL command SET ACL to manipulate (add, delete, 
or copy) entire ACLs or individual ACEs on more than one object at a 
time. 


The following DCL commands can be used to display ACLs: 
e SHOW ACL 

e DIRECTORY/ACL 

¢ DIRECTORY/SECURITY 

e DIRECTORY/FULL 


In general, and in the examples throughout this guide, you will find the 
DCL commands SET ACL and SHOW ACL sufficient for creating and 
displaying most ACLs, although the ACL editor is an important utility for 
more extensive ACL work. 
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You can establish ACLs for various system objects: files, directory files, 
global sections, devices, queues, and system logical name tables. Be aware 
of the special considerations described in the following sections when 
creating ACLs on objects other than files. 


4.3.2.1 Global Sections 
ACLs on global sections (except those backed by disk files) are not saved 
and must be reestablished every time the section is created. 


The ACL on a global section backed by a file is the ACL of the file. 
Changing the file’s ACL causes a corresponding change in the global 
section’s ACL. You cannot change the ACL on other types of global 
sections. 


You can establish ACLs on both system and group global sections. Note, 
however, that if you attempt to access a group global section outside your 
UIC group, the operating system denies access and does not consider 
the ACL. ACLs on PFN and page file global sections can be set up and 
modified with the ACL editor or with the following commands: 


$ SET ACL/OBJECT_TYPE=SYSTEM GLOBAL SECTION section_name 
$ SET ACL/OBJECT_TYPE=GROUP_GLOBAL_ SECTION section_name 


4.3.2.2 Devices 
You must reestablish ACLs on devices every time the system is booted 
because they are not saved. ACLs on devices are set up and modified with 
the ACL editor or with the following command: 


$ SET ACL/OBJECT_TYPE=DEVICE device-name 


4.3.2.3 Logical Name Tables 
ACLs on logical name tables are not saved and must be reestablished 
every time the tables are created. ACLs can be established for system 
logical name tables but not process logical name tables. ACLs on system 
logical name tables are set up and modified with the ACL editor or with 
the following command: 


$ SET ACL/OBJECT TYPE=LOGICAL NAME TABLE table-name 


4.3.2.4 Queues 
ACLs on batch and device (printer, server, and terminal) queues are saved 
in the queue file (JBCSYSQUE.DAT in the SYS$SYSTEM directory) and 
do not need to be reestablished every time the system is booted. 


Set up or modify ACLs on queues with the ACL editor or with the 
following command: 


To deny access to a queue for specific users or groups of users, set up an 
ACL on the queue denying users all access to the queue, as shown in the 
following example: 


$ SET ACL/OBJECT_TYPE=QUEUE/ACL= ( (IDENTIFIER=JONES, ACCESS=NONE), ~- 
_$ (IDENTIFIER=[DOC, *],ACCESS=NONE)) LNO3S$PRINT 


All users except JONES and users in the DOC UIC group can submit jobs 
to the LNO3$PRINT queue. 
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To mit access to a queue, remove World WRIlm access to the queue, and 
set up an ACL specifying access for all users permitted to submit jobs to 
the queue. In the following example, only holders of the general identifier 
PROJECTX can submit jobs to the LNO3$PRINT queue. An additional 
ACE is granted allowing user PIAZZA operator (OPER) privileges to the 
queue. (If PIAZZA also holds the PROJECTX identifier, as assumed in this 
example, then the ACE granting PIAZZA operator privileges must appear 
first in the ACL.) 


$ SET QUEUE/PROTECTION=(W:) LNO3SPRINT 
§ SET ACL/OBJECT_TYPE=QUEUE - 

$ /ACL=( (IDENTIFIER=PIAZZA, ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL), — 
_$ (IDENTIFIER=PROJECTX, ACCESS=WRITE)) LNO3$PRINT 


identifiers 


Note: If you place an ACL on a generic queue, place an identical ACL on 


all associated execution queues. 


Identifiers in an ACL specify the users who are allowed or denied access to 
an object. Following are the three types of identifiers: 


¢ UIC identifiers depend on the user identification codes (UICs) 
that uniquely identify each user on the system. Typically the UIC 
identifiers are presented in numeric or abbreviated alphanumeric 
format. For example, a UIC identifier might adopt the numeric 
format of the UIC, such as [806,210], or just the member name 
from the alphanumeric format UIC, such as JONES, where the full 
alphanumeric UIC is [GROUP1,JONES]. 


¢ General identifiers are defined by the security administrator in 
the system rights database to identify groups of users on the system. 
For example, TERM3BIO, WARD5WORKERS, DATAENTRY, and 
RESERVDESK would identify the third term biology students, the 
campaign workers for Ward 5, the data entry personnel, or the people 
who handle the reservations desk, respectively. 


e System-defined identifiers describe certain types of users based on 
their use of the system. For example, BATCH, NETWORK, DIALUP, 
INTERACTIVE, LOCAL, and REMOTE would correspond directly to 
the descriptions in Section 3.1.1 of the type of login the user executed. 


When you log in, the identifiers you hold in the rights database (including 
your UIC and your system-defined identifiers) are copied into a rights 
list that is part of your current process. The rights list is the structure 
that VMS uses to perform all protection checks. Additional identifiers 
may appear in your rights list; they were put there either by VMS Login 
software or by software specific to your installation. These identifiers 
represent qualifications about your login and the state of the system. 
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4.3.3.1 


4.3.3.2 


4.3.3.3 


UIC Identifiers 

While the most common types of UIC identifiers are either numeric format 
UICs or user names, full alphanumeric UICs or UICs in hexadecimal 
format are accepted as UIC identifiers. Thus, you might see the following 
UIC identifiers: 


[PROGRAMMERS, J_JONES] {alphanumeric format UIC} 

J_JONES {username from alphanumeric format UIC} 
[341,311] {numeric format UIC} 

%X08001006 {hexadecimal format UIC} 


Each of these formats uniquely identifies a user. 


General Identifiers 

A general identifier, defined in the system rights database, is an 
alphanumeric string of 1 through 31 characters that must contain at 
least one alphabetic character. It can include the characters A through Z, 
dollar signs ($), underscores (_), and the numbers 0 through 9. 


The security administrator uses the Authorize Utility (AUTHORIZE) to 
create and assign general identifiers and UICs to system users. 


System-Defined Identifiers 

System-defined identifiers are automatically defined by the system when 
the rights database is created at system installation time. The following 
identifiers, which correspond directly to the login classes that Section 3.1.1 
describes, are system-defined: 


BATCH All access attempts made by batch jobs 

NETWORK All access attempts made by DECnet tasks 

INTERACTIVE All access attempts made by interactive processes 

LOCAL All access attempts made by users logged in at local 
terminals 

DIALUP All access attempts made by users logged in at dialup 
terminals 

REMOTE All access attempts made by users logged in through a 
network 


In addition, a system node identifier of the form SYS$NODE_node_name 
is created by the site-independent startup procedure (STARTUP.COM in 
SYS$SYSTEM). 


A user automatically becomes a holder of one or more of these identifiers 
during login. The VMS Login software adds the appropriate identifiers to 
the process rights list. 


Access Control List Entries 
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The security administrator first creates identifiers in the rights database 
and assigns users as holders of the identifiers, then defines which access to 
grant or deny holders of the identifier for each object requiring this level of 
protection. Because several identifiers may be required to represent access 
needs for each object, it is typical to create a list of multiple entries. Each 
entry defines the access rights to be granted or denied the holders of the 
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identifier named in that entry. This list is the access controi iist, or ACL. 
Each entry in this list is called an access control list entry (ACE). 

Like the defaults for UIC-based protection, security administrators can 
set up default ACLs. As a result, some users may be unaware that their 


files have ACLs and may never change ACLs themselves. Other users are 
actively. involved in creating and maintaining their own ACLs. 


To summarize, ACLs can be created by the system by default, by the 
security administrator for specific objects, and by users to protect their 
own files. Users can create ACLs only for objects they own or to which 
they have the same access as the object owner. 


An ACL consists of ACEs that grant or deny access to a particular system 
object, such as a file, directory, or device. Because ACLs can define access 
more selectively than UIC-based protection, ACLs allow users to fine tune 
the action taken when access is requested for an object. Typically, you use 
ACLs to provide users from several UIC groups access to a system object 
without having to grant WORLD access to the object. ACLs can perform 
other functions, such as directing security alarms to be set off when access 
to an object succeeds or fails. 


When the system receives a request for access to an object that has an 
ACL, the system searches each entry in the ACL sequentially for the 
first match. It stops searching at the first match. If another match exists 
further down in the ACL, it has no effect. Thus, ACEs that identify 
specific users should appear in the ACL before ACEs that identify broader 
classes of users, as follows: 


(IDENTIFIER=WILLIAMS , ACCESS=READ+EXECUTE) 
(IDENTIFIER=CS101, ACCESS=NONE) 


Assume that user WILLIAMS holds the CS101 identifier. In the previous 
example, WILLIAMS is granted READ and EXECUTE access to the object. 
If the ACEs were switched, user WILLIAMS may be denied access to the 
object. 


The use of ACLs is optional. Although the use of ACLs can enhance the 
security of system objects in any installation through a more detailed 
definition of who is allowed what kind of access, user time must be spent 
in creating and maintaining the ACLs, and processor time is required to 
perform the functions that ACLs mandate. 


Each ACL consists of one or more ACEs. There is no limit to the number 
of ACEs that an ACL can contain or to the number of characters in an 
ACE; however, very long ACLs increase the amount of time necessary to 
gain access to an object. 


The type of access protection needed determines the type of ACE used in a 
given situation. Following are three types of ACEs involved with security: 


¢ Identifier ACE—Controls the type of access allowed to a particular 
user or group of users. 


¢ Default protection ACE—Defines the default protection for a 
directory so protection can be propagated to the files and subdirectories 
created in that directory. (This type of ACE is applicable only to 
directory files.) 


4-21 


Object Protection Features 
4.3 Access Control Lists (ACL) 


4-22 


4.3.4.1 


e Security alarm ACE—Provides an alarm message when an object is 
accessed to help alert managers to possible security threats. 


The exact format of an ACE depends on its type, but all ACEs are enclosed 
in parentheses. In general, the format of an ACE is as follows: 
(type[,options][,access_to_grant]) 

Identifier ACE 


An identifier ACE controls the types of access allowed to specific users 
based on user identification. Following is the format for an identifier ACE: 


(IDENTIFIER=identifier[,options][,access]) 


Specifying Identifiers in Identifier ACEs 


The first field in the identifier ACE is the keyword IDENTIFIER followed 
by one or more identifiers. An identifier can be one of the following: 


© User identification code (UIC) 


¢ General, established by the system manager in the system rights 
database 


e System-defined 


A UIC can be in either numeric or named UIC format, as described in the 
VMS DCL Concepts Manual. 


A general identifier, defined in the system rights database, is an 
alphanumeric string of 1 through 31 characters that must contain at 
least one alphabetic character. It can include the characters A through Z, 
dollar signs ($), underscores (_), and the numbers 0 through 9. 


The system manager creates and assigns general identifiers and UICs to 
system users using the Authorize Utility (AUTHORIZE). 


System-defined identifiers are automatically defined by the system when 
the system manager creates a rights database. The following identifiers 
are system-defined identifiers: 


BATCH Ail attempts at access made by batch jobs 

NETWORK All attempts at access made over the DECnet-VAX network 
INTERACTIVE Ail attempts at access made by interactive processes 

LOCAL All attempts at access made by users logged in at local terminals 
DIALUP All attempts at access made by users logged in at dialup terminals 
REMOTE All attempts at access made by users logged in via a network 


Generally, use only one of the six system-defined identifiers at a time. You 
can use them with other identifiers (UICs and general identifiers). When 
you specify multiple identifiers, connect them with plus signs (+). 


The system takes the access action included in the ACE only for the user 
who matches all the identifiers. For example, if you wanted to grant read 


access to user [301,25] running a batch job, you would specify the identifier 


ACE as follows: 
(IDENTIFIER=[301 ,25]+BATCH,ACCESS=READ) 


we 
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Although it is unusual for a number of users to share the same UIC, it 

is likely that a number of users will share the same general identifier. 
Users with the same general identifier do not need to be in the same 
UIC-based group. Furthermore, a single user can be associated with a 
number of different general identifiers as defined in the rights database. 
The creator of an ACL has considerable flexibility in selecting sets of users 
and defining access capabilities for them. 


For example, the user identified by the UIC [801,25] is a member of the 
UIC-based group 301. That user may be the only member of group 301 
who is also associated with the general identifier PERSONNEL. An ACE 
defining a particular type of access for the users associated with the 
general identifier PERSONNEL grants that type of access to that user, but 
not to the other members of group 301. 


Specifying Options in Identifier ACEs 


The options field in an identifier ACE controls whether an ACE is 
propagated, can be displayed, or can be deleted. This field in an identifier 
ACE begins with the keyword OPTIONS and takes one or more of the 
following keywords: 


DEFAULT Indicates that an ACE is to be included in the ACL of any files 
created within a directory. When the ACE is propagated, the 
DEFAULT indicator is removed from the ACL of the created file. 
This option is valid only for directory files. A default ACE does 
not grant or deny access; it just affects the ACL of new files. 


HIDDEN Indicates that this ACE should only be changed by the 
application that added it. The ACL editor generally does not 
permit modification or deletion. Thus, the ACL editor displays 
the ACE only to show its relative position within the ACL, not to 
facilitate editing of the ACE. The DCL DIRECTORY and SHOW 
ACL commands do not display hidden ACEs unless the user 
holds the SECURITY privilege. 


PROTECTED Indicates that an ACE will be preserved even when an attempt 
is made to delete the entire ACL. A protected ACE must be 
deleted specifically with the ACL editor or by specifying the ACE 
on the command line of the DCL command SET ACL. 


NOPROPAGATE Indicates that, when copying an ACL from one version of a file 
to a later version of the same file, the ACE is not copied to the 
newer version. 


NONE Indicates that no options apply to an ACE. Although you 
can enter OPTIONS=NONE when you create the ACE, 
OPTIONS=NONE is not displayed when the ACE is displayed. 


Connect multiple options with plus signs (+). If you specify any other 
options with the NONE option, the other options take precedence. 


Identifier ACE for a Directory 


The OPTIONS=DEFAULT option of an identifier ACE allows users to 
define one or more default ACEs for inclusion in the ACLs for files created 
in a particular directory. A default ACE is supplied for all new files 
created in that directory; any existing files are not supplied with the 
default ACE. Thus, if you wanted all files in the directory [MALCOLM] 

to have an ACE that permitted read and write access to users with the 
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PERSONNEL identifier, you could include the following ACE in the ACL 
for the file MALCOLM.DIR: 


(IDENTIFIER=-PERSONNEL,OPTIONS=DEFAULT,ACCESS=READ+WRITE) 


As a result of this ACE, any file created in the [MALCOLM] directory has 
the following ACE: 


(IDENTIFIER=-PERSONNEL,ACCESS=READ+WRITE) 


Notice that the DEFAULT option does not appear in the file’s ACE. 
However, any subdirectory created in the MALCOLM directory has the 
DEFAULT option as part of its ACE so that the default ACE will be 
propagated throughout the entire directory tree. 


Note: ACEs with the DEFAULT option are not used when performing a 


protection check. 


Specifying Access in Identifier ACEs 


The third field in an identifier ACE specifies what type of access you are 
allowing the users identified in the first field of the ACE. This field begins 
with the keyword ACCESS followed by a string of access actions connected 
by plus signs. The following types of access are allowed in an identifier 
ACE: 


READ Accessor can read a file, read from a disk, or allocate a device. 

WRITE Accessor can read or write a file. 

EXECUTE Accessor can execute an image file or look up entries in a directory 
by explicitly specifying file names. 

DELETE Accessor can delete a file. 

CONTROL Accessor has all the privileges of the object’s owner. 

NONE Accessor has no access to the object. 

Sample Identifier ACEs 


The most common type of ACL is one that defines the access to a file for 
a group of users. In the following ACL example, access to a file is based 
on the identity of a user. PERSONNEL, SECURITY, and SECRETARIES 
are general identifiers assigned to appropriate sets of users by the system 
manager using AUTHORIZE. NETWORK is a system-defined identifier, 
while [20,*] and [SALES,JONES] are examples of UIC identifiers. 


(IDENTIFIER=SECURITY, OPTIONS=PROTECTED, ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) 
(IDENTIFIER=PERSONNEL, ACCESS=READ+WRITE+EXECUTE+DELETE) 

(IDENTIFIER=SECRETARIES, ACCESS=READ+WRITE) 

(IDENTIFIER=[20, *] , ACCESS=READ) 

(IDENTIFIER=NETWORK, ACCESS=NONE) 

(IDENTIFIER=[SALES, JONES] , ACCESS=NONE) 
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In the preceding example, the ACE providing the greatest amount of 
file access is listed at the top of the ACL. Any users holding both the 
SECURITY and PERSONNEL identifiers obtain maximum access rights 
through the first match, which is the SECURITY identifier. In this 
example, the user with UIC [SALES,JONES] is prohibited from any 
access to the file unless that user also happens to have one of the general 
identifiers (which is an oversight on the part of the creator of the ACL). 


xo 


7 a 


4.3.4.2 
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if tne ACL creator wants to be absolutely certain that the user with UIC 
{[SALES,JONES] could not possibly gain access to the file, the ACE at the 
bottom of the ACL should be moved to the top. 


The order of the ACEs in the example permits a number of users to gain 
types of file access over the DECnet—VAX network. The users with the 
identifiers of SECURITY, PERSONNEL, SECRETARIES, and UIC [20,*] 
can all gain some access over the network, although only those with 

the identifier SECURITY can gain full access. The fifth ACE prevents 
all other users from network access. While this might be the intent of 
the ACL creator, it would be an unfortunate oversight if it were not. 
Remember that the system searches the ACL sequentially and grants the 
user only the access specified in the first matching ACE. All subsequent 
ACEs are ignored. 


The first ACE is the only ACE containing an option field (the 
PROTECTED option). Using this option prevents the first ACE from being 
deleted unless you have explicitly deleted the ACE with the ACL editor, or 
you have specified the ACE with the SET ACL/DELETE command. 


Identifier ACEs for Other Objects 


Create identifier ACEs for other system objects, such as devices, as you 
create ACEs for files or directories. For example, suppose your company 
has a special letter-quality printer (TTA8) that is used only for printing 
checks. As a result, the check forms are always loaded in the printer. 
This device is never to be used for logins, and no queues are directed to 
it. Only one user, MGREY, is allowed read and write access to it. The 
system manager can establish this restriction by setting the protection on 
the printer with the following command: 


$ SET PROTECTION=(S,0,G,W) /DEVICE TTA8: 


The following identifier ACE, applied to the object TTA8, restricts access 
to the device: 


(IDENTIFIER=MGREY, ACCESS=READ+WRITE) 


Default Protection ACE 

The default protection ACE is used to ensure that one type of UIC-based 
protection is propagated throughout a directory tree. This type of ACE 
allows you to specify protection for one directory structure that is different 
from the default protection applied to other directories. Default protection 
ACEs can be applied only to directory files. 


Following is the format for a default protection ACE: 
(DEFAULT_PROTECTIONTL, options], protection_mask) 


This type of ACE is specified by the keyword DEFAULT_PROTECTION. 
The second field (the options field) in a default protection ACE controls 
whether an ACE is propagated, can be displayed, or can be deleted. This 
field in a default protection ACE begins with the keyword OPTIONS and 
takes one or more of the following keywords: 
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HIDDEN 


PROTECTED 


NOPROPAGATE 


NONE 


Indicates that this ACE can only be changed by the application 
that added it. The ACL editor generally does not permit 
modification or deletion. Thus, the ACL editor displays the 
ACE only to show its relative position within the ACL, not to 
facilitate editing of the ACE. The DCL DIRECTORY and SHOW 
ACL commands will not display hidden ACEs unless the user 
holds the SECURITY privilege. 


Indicates that an ACE is preserved even when an attempt 

is made to delete the entire ACL. A protected ACE must be 
specifically deleted with the ACL editor or by specifying the ACE 
on the command line of the DCL command SET ACL. 


Indicates that, when copying an ACL from one version of a file 
to a later version of the same file, the ACE is not propagated. 


Indicates that no options apply to an ACE. Although you 
might enter OPTIONS=NONE when you create the ACE, 
OPTIONS=NONE is not displayed when the ACE is displayed. 


Connect multiple options with plus signs (+). If you specify any other 
options with the NONE option, the other options will take precedence. 


The protection mask is specified the same as for UIC-based protection, 
with the user categories—SYSTEM, OWNER, GROUP, and WORLD—and 
the access categories—READ, WRITE, EXECUTE, and DELETE. See the 
discussion of UIC-based protection in the VMS DCL Dictionary for more 


information. 


The following sample ACE, included in an ACL for the directory 


MALCOLM, sets up default protection so that any files created in the 
directory allow system and owner groups read, write, execute, and delete 
access. Group and world groups are denied access. 


(DEFAULT_PROTECTION,S:RWED,O:RWED) 


When you add or change the default protection for a directory, there is no 
effect on the files already created in the directory. All new files will receive 
the default protection. 


If you want to have the default protection ACE PROTECTED, which \ 
saves its ACE if an attempt is made to delete the entire ACL, create the 


following ACL: 


(DEFAULT_PROTECTION,OPTIONS=PROTECTED,S:RWEDC,O:RWEDC,G,W) 


Security Alarm ACE 

The security alarm ACE specifies the file access criteria which, if met, 
results in an alarm message that is sent to all security operator terminals. 
(Chapter 6 describes how to use the SET AUDIT and REPLY/ENABLE 
commands to enable a security operator’s terminal to receive security 
alarms.) Note that the use of security alarm ACEs on system objects other 
than files is not supported. 


Although you can create alarm ACEs in an ACL that cause the system to 
observe the event and take the required action, you should also coordinate 


protection with your system’s security administrator (the person who 


— 


possesses the SECURITY privilege). The security administrator is \ 
responsible for enabling the alarm feature. Since this feature uses system 
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resources, the security administrator might be reiuciant to leave it enabiead 
at all times. 


Following is the format of a security alarm ACE: 
(ALARM_JOURNAL=SECURITY|,options][,access]) 


This type of ACE is specified by the keywords ALARM _ 
JOURNAL=SECURITY. The second field in a security alarm ACE begins 
with the keyword OPTIONS, which takes one or more of the following 
keywords: 


DEFAULT This option is valid only for directory files. Indicates that an 
ACE is to be included in the ACL of any files created within a 
directory. When the ACE is propagated, the DEFAULT indicator 
is removed from the ACL of the created file. 


HIDDEN Indicates that this ACE can only be changed by the application 
that added it. The ACL editor generally does not permit 
modification or deletion. Thus, the ACL editor displays the 
ACE only to show its relative position within the ACL, not to 
facilitate editing of the ACE. The DCL DIRECTORY and SHOW 
ACL commands will not display hidden ACEs unless the user 
holds the SECURITY privilege. 


PROTECTED Indicates that this ACE is preserved even when an attempt 
is made to delete the entire ACL. A protected ACE must be 
explicitly deleted with the ACL editor or by specifying the ACE 
on the command line of the DCL command SET ACL. 
NOPROPAGATE Indicates that, when copying an ACL from one version of a file 
to a later version of the same file, the ACE is not propagated. 
NONE Indicates that no options apply to this ACE. Although you enter 


OPTIONS=NONE when you create the ACE, OPTIONS=NONE 
is not displayed when the ACE is displayed. 


Connect multiple options with plus signs (+). If you specify any other 
options when specifying NONE, the other options take precedence. 


The third field in an alarm ACE controls the type of access that causes 
the alarm to be sent. Specify any of the following access actions with the 
ACCESS keyword: 


READ Generates an alarm if an accessor attempts to read the object. 

WRITE Generates an alarm if an accessor attempts to read or write the 
object. 

EXECUTE Generates an alarm if an accessor attempts to execute the 
object. 

DELETE Generates an alarm if an accessor attempts to delete the object. 

CONTROL Generates an alarm if an accessor attempts to perform control 
operations on the object, such as changing the protection on the 
object. 

SUCCESS Generates an alarm for each successful attempt by an accessor 
to access the object. 

FAILURE Generates an alarm for each unsuccessful attempt by an 


accessor to access the object. 
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For an alarm ACE to have any effect, you must include SUCCESS or 
FAILURE or both. For example, the following security alarm ACE, when 
applied to a file, sends an alarm message to security operator terminals 
when any attempt is made to read or write the file: 


(ALARM_JOURNAL=SECURITY,ACCESS=READ+WRITE+SUCCESS+FAILURE) 


4.3.5 Summary of ACLs 


The following recommendations will help you manage ACLs: 


¢ Do not assume that specifying ACCESS=NONE for an identifier will 
absolutely prohibit the holders of the identifier from accessing the 
object. Frequently, users in either the SYSTEM or OWNER category 
may still be entitled to whatever access the UIC-based protection 
affords that category. If the users hold special privileges, they may be 
granted the access requested through the privilege. 


e Ensure that the order that ACEs appear in the ACL is correct. Place 
the ACEs that deny access to specific users at the top of your ACLs, 
so that the user will not obtain access by holding another identifier. 
Sometimes you use wildcards in the UIC-format identifiers to deny 
access to large groups of users. Such an ACE properly belongs at the 
bottom of the ACL, not at the top. Place the ACEs that grant the 
widest access rights immediately before the most restrictive ACEs. | 
This technique ensures that users who hold multiple identifiers do 
not obtain restricted access rights on the first match when another 
identifier they hold could grant more generous rights. Remember that 
a user can only receive the access rights granted through the first 
matching identifier. 


¢ Do not place ACLs on all objects. This is usually unnecessary even at 
medium-level security sites. Too many ACLs can cause performance 
slowdowns to occur on the system. Instead of using ACLs on individual 
files, group files so that only a few directories need default ACEs that 
propagate to many or all files. 


¢ Use general identifiers to create practical groups of users to avoid 
unnecessarily long ACLs. 


¢ Update ACLs when you delete user accounts. Always maintain the 
shortest and most current ACLs. Again, using general identifiers 
instead of individual users helps alleviate this maintenance problem. 


4.4 Establishing and Changing Object Ownership 
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This section describes how VMS establishes the ownership of resources 
such as volumes, directories, and files. It includes an explanation of the 
attributes users may have associated with some of their identifiers and 
how those attributes can affect the default file ownership. The section also 
describes the requirements VMS imposes on users before allowing them to 
change object ownership. The appropriate DCL commands are given. 
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4.4.1. Understanding the Role of Identifier Attributes 


4.4.1.1 


4.4.1.2 


Attributes are identifier characteristics that you can specify when adding 
identifiers to the rights database or granting identifiers to users. You can 
specify the following attributes when adding or granting identifiers: 


¢ Resource—Allows holders of the identifier to charge disk space to the 
identifier 


e Dynamic—Allows holders of the identifier to remove the identifier from 
the process rights list using the DCL command SET RIGHTS_LIST 


Resource Attribute 

Consumption of disk space is generally charged to the creator of each file 
by subtracting the disk space from the file owner’s disk quota. System 
managers and security administrators may prefer to track the use of disk 
space according to logical groups of users (such as departments or projects) 
rather than individual users. General identifiers can specify these groups. 
Thus, when general identifiers own directories, disk space used by files 
created in the directories is charged to the identifier. 


To allow file space to be owned by and charged to an identifier, specify the 
resource attribute when adding the identifier to the rights database using 
AUTHORIZE, as shown in the following example: 


$ SET DEFAULT SYSSSYSTEM 
$ RUN AUTHORIZE 
UAF> ADD/IDENTIFIER MGMT101 /ATTRIBUTES=RESOURCE 


To allow specific holders of the identifier to charge disk space to the 
identifier, perform the following steps: 


1 Grant the identifier with the resource attribute to all desired users, as 
follows: 


UAF> GRANT/IDENTIFIER MGMT101/ATTRIBUTES=RESOURCE JONES 


2 Add the appropriate ACEs to the desired directory to give users 
CONTROL access to the directory owned by the identifier, as follows: 


$ SET ACL/ACL= (IDENTIFIER=JONES, ACCESS=CONTROL) INVENTORY.DIR 


Not everyone who holds the identifier will also hold the resource attribute 
associated with that identifier. If you create a file in a directory owned by 
an identifier, and you do not have the resource attribute for that identifier, 
the required disk space is subtracted from your disk quota. 


Dynamic Attribute 

Once you grant an identifier to a user, the user usually holds the identifier 
(in the process rights list) until logged out. However, if you grant the 
identifier with the dynamic attribute, the user who holds the identifier can 
use the DCL command SET RIGHTS_LIST to add or remove the identifier 
or its attributes from the process rights list as needed. 
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To allow users to modify an identifier, specify the dynamic attribute when 
adding the identifier to the rights database using AUTHORIZE, as shown 
in the following example: 


$ SET DEFAULT SYSSSYSTEM 
$ RUN AUTHORIZE . 
UAF> ADD/IDENTIFIER MGMT101 /ATTRIBUTES=DYNAMIC 


To allow specific holders of the identifier to modify the identifier, include 
the dynamic attribute when granting the identifier, as follows: 


UAF> GRANT/IDENTIFIER MGMT101/ATTRIBUTES=DYNAMIC JONES 


User JONES enters the following command to remove the MGMT101 
identifier from the process right list: 


$ SET RIGHTS LIST/DISABLE MGMT101 


Users who hold identifiers with the dynamic and resource attributes can 
also use the SET RIGHTS_LIST command to remove just the resource 
attribute on the identifier. See the VMS DCL Dictionary for a complete 
description of the SET RIGHTS_LIST command. 


Because users may be able to circumvent system security by removing 
their identifiers, be careful when granting users an identifier with the 
dynamic attribute. If a user who holds an identifier with the dynamic 
attribute removes the identifier from the rights list, and holders of the 
identifier were explicitly denied access in an ACL, the user may then gain 
access to the object through another ACE in the ACL. 


As a privileged security administrator, you can use the SET RIGHTS_ 
LIST command to modify the rights list of any process on the system or 
to modify identifiers in the system rights list. The following privileges are 
required: 


¢ Modifying identifiers of processes in your UIC group requires 
CMKRNL and GROUP privileges. 


¢ Modifying identifiers of any process on the system requires CMKRNL 
and WORLD privileges. 


¢ Modifying the system rights list requires CMKRNL and SYSNAM 
privilege. 


4.4.2 Defining Ownership Privileges 
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This section describes the conditions that qualify a user to set or change 
ownership of an object. The user who meets these conditions has 
ownership privileges for the object. That is, the user may or may not 
be the recorded owner for the object, but by possessing a VMS privilege or 
holding an identifier with the resource attribute, the user may be entitled 
to set or change the ownership. 


The conditions required to convey ownership privileges for files and 
directories are identical. (The conditions for conveying ownership 
privileges for volumes differ. See Section 4.4.3.) 
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Users need to satisfy only one of these conditions to receive ownership 
privileges: 


¢ Hold the same UIC as the object 


¢ Hold the resource attribute to the identifier that owns the object while 
also being allowed CONTROL access to the object through an ACL on 
the object 


¢ Qualify as members of the SYSTEM user category, hold SYSPRV or 
BYPASS privilege, or hold a UIC that matches that of the owner of the 
volume containing the file or directory 


e Hold the GRPPRV privilege while also holding a UIC in the same 
group as the object owner 


If a user wants to establish the ownership for a new object, the user must 
have ownership privileges for the identifier that owns the object. However, 
if the user wants to change the ownership of an existing object, the user 
must have ownership privileges for both old and new owner identifiers. 


4.4.3. Establishing and Changing Volume Ownership 


The ownership of a volume is established when you initialize the volume 
with the DCL command INTITIALIZE. Unless you specify an owner with 
the qualifier /OWNER_UIC, the owner of the volume defaults to your 
current process. 


Display volume ownership with the DCL command SHOW 
DEVICES/FULL. 


To change the owner of a volume, enter the DCL command SET 
VOLUME/OWNER_UIC. Only users who can match one of the following 
criteria can change the ownership of the volume: 


¢ Qualify as a member of the SYSTEM category of users 
e Hold the SYSPRV privilege 


¢ Own the volume 


4.4.4 Establishing and Changing Directory Ownership 


Ownership of directories is usually set when the directory is created 
with the DCL command CREATE/DIRECTORY. A user with ownership 
privileges (see Section 4.4.2) can specify the owner by using the DCL 
command CREATE/DIRECTORY/OWNER_UIC. If no owner is explicity 
specified, VMS assigns a default owner, as follows: 


e If the directory name is in alphanumeric or subdirectory format, 
ownership defaults to the owner UIC of the existing parent directory 
if the user has ownership privileges to that UIC; if not, the ownership 
defaults to the UIC of the process issuing the command. 


e Ifthe directory name is in UIC format, the ownership defaults to the 
UIC in the directory name. 
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Display the directory file owner by entering the DCL command 
DIRECTORY/OWNER. For example, to check the directory file ownership 
for all top-level directories, use the following command: 


$ DIRECTORY/OWNER [000000]*.DIR 
View the owners of all your subdirectories with the following command: 
$ DIRECTORY/OWNER [...]*.DIR 


However, if there are subdirectories for which you are not the owner and 
you fail the protection check, you will be unable to view owner information. 


If you have ownership privileges to the directory, you can change the 
directory file ownership with the DCL command SET FILE/OWNER_ 
UIC. For example, to change the current owner of the subdirectory 
[MONROE.WEATHER] to [CHEM4,LEONARD], you would enter the 
following command: 


$ SET FILE/OWNER_UIC=[CHEM4, LEONARD] [MONROE]WEATHER.DIR 


The same rules of establishing and changing directory ownership apply 
when the directory is owned by a general identifier. 


4.4.5 Establishing and Changing File Ownership 


4-32 


The VMS operating system selects a default owner for a file in the 
following order: ( 


1 An attempt is made to propagate the ownership from a previous 
version of a file. This succeeds only if the user has ownership 
privileges to the previous version. (Ownership privileges are defined in 
Section 4.4.2.) 


2 Ifthe attempt to propagate from the previous version fails (either 
because there is no previous version or the file creator lacks ownership 
privileges to the previous version), then an attempt is made to 
propagate ownership from the parent directory. This succeeds only if 
the user has ownership privileges to the parent directory. (Ownership % 
privileges are defined in Section 4.4.2.) 


3 Ifthe attempt to propagate from the parent directory fails, the owner 
of the file is the same as the creator of the file. 


~ 
" 


Users with ownership privileges can specify an alternative file owner with 
the DCL command CREATE/OWNER_UIC. 


You can display the current file owner with the DCL command 
DIRECTORY/OWNER. However, if there are files in the directory for 
which you are not the owner and you fail the protection check, you will be 
unable to view the owner information. 


Only those users who have ownership privileges (see Section 4.4.2) can 
change file ownership. If you have ownership privileges, you can change 
file ownership with the DCL command SET FILE/OWNER_UIC. 


a 
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4.5 Propagation of Protection Defaults 


This section describes ACL protection defaults for directories and files. It 
also explains propagation of both UIC-based and ACL-based protection. 


4.5.1 Default Directory File Protection 


4.5.1.1 


4.5.1.2 


Directory file protection establishes protection and provides default 
values that can be applied to files added to the directory when they lack 
specifications of their own. Both UIC-based protection and ACL protection 
can be placed on directory files. 


Default UIC-Based Directory File Protection 

Directory files receive their file protection codes at creation time. The 
directory file protection code of a subdirectory defaults to that of its 
next higher level directory. The default protection code of a top-level 
directory comes from the volume master file directory. The creator of the 
directory always has the option of specifying a protection code with the 
DCL command CREATE DIRECTORY/PROTECTION. 


You can change the directory file protection by using either of the DCL 
commands SET PROTECTION or SET FILE/PROTECTION. 


Default ACL Protection 

Frequently it is efficient to set up one ACL to apply to every new 
subdirectory file to be created in the directory tree. By default, a 
subdirectory inherits the ACL of its parent. Use the NOPROPAGATE 
option in the ACL to specify which ACEs are not to be copied to newly 
created subdirectories. 


With this technique, you can also provide default ACL entries for 
propagation into ACLs for the files kept in the directory. (Use the 
DEFAULT option to specify an ACE to be copied to all files created in 
the directory.) 


4.5.2 Default File Protection 


4.5.2.1 


Note: 


All files need UIC-based protection. Some files require ACL protection as 
well. The following sections describe how to recognize needs for UIC-based 
and ACL-based default file protection, as well as how to override those 
defaults. 


To adequately protect files, you must also protect the directory in 
which the files reside. 


Default UIC-Based Protection 


If you do not define a protection code for a file when you create the file, the 
system applies a default protection code. 
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4.5.2.2 


When you create a file, protection is determined sequentially, as follows: 


1 If the file is a new version of an existing file, the new file inherits the 
protection of the existing version. 


2 If no previous version exists, and the directory where the file is 
to be stored has an associated ACL that includes a DEFAULT_ 
PROTECTION ACE, the protection specified by that ACE is used. 


3 Ifthe directory does not have a DEFAULT_PROTECTION ACE, 
the default process protection is used. VMS consults the SYSGEN 
parameter RMS_FILEPROT to establish this value during login. 
However, the value derived at login may have been overridden 
explicitly by you (or possibly by your login command procedure) with 
the DCL command SET PROTECTION/DEFAULT. 


You can determine your current process default protection by entering 
the DCL command SHOW PROTECTION, as follows: 


$ SHOW PROTECTION 
SYSTEM=RWED, OWNER=RWED, GROUP=RE, WORLD=NO ACCESS 


The system responds by displaying your default protection. In 

this example, it indicates that users in the SYSTEM and OWNER 
categories have all types of access, that members of the owner’s group 
(in the GROUP category) have READ and EXECUTE access, and that 
all other users (in the WORLD category) have no access. 


At any time during your terminal session you can change the default ( 
process protection applied to files that you create by invoking the DCL 
command SET PROTECTION/DEFAULT. 


To determine the current protection associated with a specific file or files, 
use the: /PROTECTION qualifier with the DCL command DIRECTORY, as 
follows: 


$ DIRECTORY/PROTECTION PERSONNEL.REC 

Directory USE1: [CRAMER] i 
PERSONNEL. REC; 5 (RWED, RWED, RW, R) \ 
Total of 1 file. 


Default ACL Protection 
When you create a file, it may receive an ACL by default from one of the 
following sources: 


e If the file is a new version of an existing file, the new file inherits 
the ACL of the existing one, without any ACEs marked with the 
NOPROPAGATE option. 


e Ifno previous verson of the file exists, VMS checks the directory in 
which you are creating the file for an ACL. If there is an ACL, all 
entries in the ACL marked with the DEFAULT option are copied to 
the new file with the DEFAULT option removed. 
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In addition, when you create a file whose owner identifier is not your UiC 
(by explicitly naming a file owner or through the ownership defaulting 
rules presented in Section 4.4.5), an ACE that grants CONTROL access to 
your UIC plus the access available to the owner of the file is added to the 
files ACL. This feature guarantees that you retain control over a file that 
you have just created, regardless of other defaults. 


You can use wildcards in the SET ACL command to make identical 
changes to ACLs on a large number of files. For example, if you decide 
you want to add an ACE to every ACL in your top level directory to grant 
holders of the identifier SPECIAL both READ and CONTROL access, you 
would enter the following commands: 


$ SET DEFAULT SYSSLOGIN 


$ SET ACL/ACL=- 
_$ (IDENTIFIER=SPECIAL, ACCESS=READ+CONTROL) *.*;* 


To avoid recreating ACLs, find an existing ACL that you want to copy. 
Use the DCL command SET ACL/LIKE to place a copy of an existing ACL 
on one of your files. For example, to place the ACL that currently exists 
on the file NEWTERM.MEM onto the file FALLTERM.MEM, enter the 
following command: 


$ SET ACL/LIKE=NEWTERM.MEM FALLTERM.MEM 


Since the SET/ACL/LIKE command will also accept wildcard specifications, 
you are able to copy the final edited version of the ACL to many files. 


Summary of Access Request Evaluation 


Figure 4—4 charts the sequence of procedures that VMS follows when 
evaluating an access request and shows how the three controlling 
components (ACLs, protection codes, and privileges) interact. 


4-35 


Object Protection Features 
4.6 Summary of Access Request Evaluation 


Figure 4-4 Flowchart of Access Request Evaluation 
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Figure 4—4 (Cont.) Flowchart of Access Request Evaiuation 
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Figure 4—4 (Cont.) Flowchart of Access Request Evaluation 
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Protecting Purged or Deleted Data from Disk Scavenging 


Because data exists on a disk until it is overwritten, it is necessary 

to protect deleted or purged file information from disk scavenging. 
Although a deleted or purged file header record denies normal access, a 
disk scavenger can use special programs and equipment to read those files. 
With advanced equipment, it is also possible to read the faint residual 
magnetic impressions of overwritten files. Therefore, sites with medium- 
to high-level security requirements must adequately protect against disk 
scavenging. 


The VMS operating system offers the following disk scavenging protection: 
erasure patterns and highwater marking. 
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Erasure Patterns 


An erasure pattern is a repeated sequence of bits written over a file when 
the file is deleted or purged. The system manager can automatically apply 
the erasure pattern to each deleted file by specifying the /ERASE qualifier 
when the volume is initialized, as follows: 


$ INITIALIZE/ERASE device-name[:] volume-label 


If the volume is mounted, the system manager can apply the erasure 
pattern with the following command: 


$ SET VOLUME/ERASE_ON_DELETE device-spec[:] 


Alternatively, users may be requested to specify the erasure pattern on 
a file-by-file basis by using the /ERASE qualifier when entering the DCL 
commands SET FILE, DELETE, and PURGE. 


Highwater Marking 


Highwater marking prevents users from reading file space beyond the 
areas where they have been permitted to write. The outer limit of written 
space on the file is that file’s highwater mark. This technique prevents 
users from scavenging portions of the disk for information that they did 
not actually write. 


The VMS operating system implements highwater marking on sequential, 
exclusively-accessed files, such as files output from various text editors, | 
compilers, and linkers; that is, most files a process writes. For indexed 
and shared sequential files, a technique known as erase-on-allocate 

is used in place of true highwater marking. Erase-on-allocate means 
that blocks of disk space are erased as they are allocated to the 

user. By default, highwater marking is enabled when the volume is 
initialized. The system manager or security administrator can disable 
highwater marking for a specific volume by using the DCL command SET 
VOLUME/NOHIGHWATER. 





User Auditing 


Although it is the security administrator’s job to monitor the system for 
possible break-in attempts, users can apply several techniques to assist 
the security administrator in auditing access to their account and files. 


This section describes user auditing techniques. 


Noting Your Last Login Time 


In your UAF record, VMS maintains information about last logins into 

your account. Your security administrator decides whether the system 

should display this information at login time. Sites with medium to high 
security requirements frequently display this information and ask users 

to check it for unusual or unexplained successful logins and unexplained / 
failed logins. 
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AL sant 43 
If there is a report of interactive or noninteractive login at a time when 


you were not logged in, report it promptly to your security administrator 
and change your password immediately. The security administrator can 
investigate further using the system accounting and audit logs. 


If you receive a login failure message and cannot account for the 
failure, it is likely that someone has been trying to access your account 
unsuccessfully. Check your password to ensure that it adheres to all 
recommendations for password security described in Section 3.1.3.10. If 
not, change your password immediately. 


If you expect to see a login failure message and it does not appear, or 

if the count of failures is too low, change your password immediately. 
Report either of these indications of login failure problems to your security 
administrator. 


4.8.2 Tools for Detecting System Abuse 


4.8.2.1 


The VMS operating system provides the security administrator with many 
tools to assist in detecting system abuses. Among these tools are security 
alarms, the VMS Accounting Utility, and the VMS Monitor Utility. The 
following sections describe security alarms. The Accounting and Monitor 
Utilities are discussed in the VMS Accounting Utility Manual and VMS 
Monitor Utility Manual. 


Security Alarms 

The security administrator can select one or more types of events that 
warrant special attention when they occur. The security administrator 
then directs the system to send an alarm to the terminals enabled as 
security operator terminals when such an event is detected. For example, 
the security administrator might identify one or more files for which 
WRITE access should be prohibited. An alarm can be set to indicate 
attempted penetration to these files. 


Following are events whose occurrence can trigger an alarm: 

e Selected types of access to selected files and global sections 

e Event requested by an ACL on a file or global section 

¢ Use of privilege to access files and global sections 

¢ Installation of images 

e¢ Logins, logouts, login failures, and break-in attempts 

e Modifications to the system authorization file and network proxy file 
e Changes to system and user passwords 

¢ Modifications to the rights database 

e Execution of the SET AUDIT command 


¢ Volume mounts and dismounts 


The security administrator uses the DCL command SET AUDIT to enable 
security alarms. Alarms can be added or removed as necessary. 
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Enabling too many alarms may result in the failure to monitor each alarm 
appropriately. While alarms can be a powerful tool when used judiciously, 
they quickly lose their attention-getting quality when overused. 


If you suspect your account has been broken into, change your password. 
You may then want to request that your security administrator implement 
an alarm. Once an alarm has been introduced, check with your security 
administrator periodically to see if any additional break-ins have occurred. 


Auditing Access to Sensitive Files 

If you have key files that may have been improperly accessed, you may 
want to develop a strategy with your security administrator to audit access 
to the file. 


Once you have reviewed the situation and ensured that you have done 
everything possible to protect your files with standard UIC-based 
protection and a general access control list, you may conclude that a 
security alarm is required. To specify a security alarm, you must include 
a security alarm ACE in the ACL for the file. The security administrator 
then sets up the system’s security auditing to enable alarms when files are 
accessed. 


If you suspect break-in attempts on your account, the security 
administrator might temporarily enable an alarm for all file accesses. 
The security administrator can also set an alarm to monitor READ access 
to your files to catch file browsers. 


For example, if user RWOODS and his security administrator concur that 
they must know when a highly confidential file CONFIDREVIEW.MEM is 
being accessed, RWOODS would add an ACE to the existing ACL for the 
file CONFIDREVIEW.MEM, as follows: 


$ SET ACL CONFIDREVIEW.MEM /ACL=- 
_$ (ALARM=SECURITY, ACCESS=READ+WRITE+DELETE+CONTROL+FAIL+SUCCESS) 


The security administrator would enter the following DCL commands at a 
terminal set up for security alarms: 


$ REPLY/ENABLE=SECURITY 
$ SET AUDIT/ALARM/ENABLE=ACL 


The REPLY/ENABLE command causes the terminal that issues the 
command to be enabled as a security operator. In this example, no other 
terminals have been established as security operator terminals. The 

SET AUDIT command enables the auditing of security alarms for file 
accesses involving access control list alarm ACEs. The SET ACL command 
could be entered by the security administrator from any terminal. If user 
ABADGUY accesses CONFIDREVIEW.MEM with DELETE access, the 
following alarm appears at the security operator terminal (enabled in the 
previous example): 
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EEEEEEESSESE OPCOM 7-DEC-1989 07:21:11.10 %%%%%%%%S3% 
Message from user AUDITSSERVER on BOSTON 
Security alarm (SECURITY) and security audit (SECURITY) on BOSTON, system id: 19424 


Auditable event: Attempted file access 

Event time: 7-DEC-1989 07:21:10.84 

PID: 23E00231 

Username: ABADGUY 

Image name: BOSTONSDUAO: [SYS0.SYSCOMMON. ] [SYSEXE] DELETE. EXE 
Object name: _BOSTONSDUA1: [RWOODS] CONFIDREVIEW.MEM; 1 

Object type: file 

Access requested: DELETE 

Status: %SYSTEM-S-NORMAL, normal successful completion 
Privileges used: SYSPRV 


The alarm reveals the name of the perpetrator, the method of 

access (successful deletion accomplished by using the program 
[SYSEXE]JDELETE.EXE), time of access (7:21 a.m.), and the use of a 
privilege (SYSPRV) to gain access to the file. With this information, the 
security administrator can take corrective action. 


Note that the security alarm appears at each terminal enabled as a 
security operator, which in this case is only a single terminal, every time 
any file is accessed and meets the conditions specified in the alarm ACE 
for that file. CONFIDREVIEW.MEM, as well as all files on the system 
protected with security alarm ACEs, triggers the alarm. 


An access violation of one file frequently indicates access problems with 
other files. Therefore, the security administrator may need to monitor 
access to all key files having security alarm ACEs. When undesired 
access is being gained to key files, the security administrator should take 
immediate action. 


4.9 Managing Your Files for Optimum Security 
Proper file management is an important aspect of file protection. 


¢ Do not use obvious names for your directories and the key files in 
them. For example, do not title the file that contains a salary planning 
memo, SALARYPLAN.MEM. 


¢ Purge your files regularly. Delete unnecessary files. This keeps your 
directories to a minimum and simplifies the task of regularly checking 
the protection and ownership on your files. 


¢ Use the DCL command DIRECTORY/SECURITY regularly to monitor 
the ownership, protection code, and ACLs on your files. A user who 
succeeds in obtaining sufficient privilege may change the protection 
or ownership on your files allowing access immediately and in the 
future. If you perform these checks frequently, you can detect and 
report unexplained changes in file protection or ownership. 


e Pay special attention to the protection on your mail files; normally 
they should be accessible only to you and the system (for mail delivery 
and backups). 


¢ When you place ACLs on your files, be sure you know exactly which 
users hold the identifiers you have specified. (This generally requires 
consultation with your security administrator.) 
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¢ Follow your security administrator’s recommendations to prevent disk 
scavenging. You may be requested to use the /ERASE qualifier on the 
SET FILE, DELETE, and PURGE commands for some or all of your 
files. 


e Always protect files and directories that contain command procedures 
and executable programs. Carefully control the granting of WRITE 
access to these directories and files. This is particularly important if 
you have any of the more powerful privileges or access to sensitive 
files. 


Caution: Do not run a command procedure or program given to you 
by another user unless you inspect it. Inspect a program or 
procedure to see if it tries to exercise your special privileges or 


access sensitive files. Test the software in an unprivileged account. 


Programs or command procedures offered under one guise, when 

- actually intended to penetrate your defenses and disrupt your 
system security, are sometimes called Trojan horse programs, 
because they parallel the theme of that Greek legend. 


- 
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5 System Security Implementation 


This chapter explains how security administrators can implement security 
features of the VMS operating system. Descriptions are based on the 
security needs of a commercial installation with average security needs, 
such as files and accounts requiring protection. Descriptions of above- 
average security needs are noted as such. 


Digital recommends that you read the entire chapter before establishing 
any security measures. After reading the chapter, you will better be able 
to decide which security measures are appropriate for your site, and you 
will have the tools to implement them. 


The Authorize Utility (AUTHORIZE) is the primary tool for implementing 
system security. AUTHORIZE is described fully in the VMS Authorize 
Utility Manual. The System Generation Utility (SYSGEN) and many DCL 
commands are also important security tools. For more information about 
SYSGEN, see the Guide to Setting Up a VMS System and the VMS System 
Generation Utility Manual. DCL commands are described in the VMS 
DCL Dictionary. 





5.1 Security Management Account 


Security administrators require accounts with privileges. In many cases, 
the security administrator and system manager roles are performed by 
the same person, so the same account can serve both. The Guide to 
Setting Up a VMS System describes the necessary characteristics of a 
system management account. It is important that strong cooperation and 
open communication exist when the security management and system 
management roles are performed by separate individuals. 


The security administrator requires the additional SECURITY privilege to 
enable security auditing and to set up security operator terminals. 


5.2 Considerations for Establishing User Accounts 


The security administrator performs user training, assigns accounts and 
passwords, and monitors user actions. This section describes guidelines 
for all interaction with users. 


A security administrator bases decisions about setting up user accounts 
on the needs of the particular site. You have the option to develop one 
or more templates that work for many of your users. However, do not 
oversimplify the process of account creation to the point that you simply 
apply a template. The danger in relying solely on templates is that you 
might overlook special considerations that apply to individual users, 
thereby forfeiting important controls that only you can exercise. 


Examine templates regularly to be sure they are valid and reflect the way 
you want your operations to proceed. Templates become obsolete rapidly. 
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5.2.1. Introduction to Group Design 
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As you design user groups, remember that the groups you establish 
have an impact on file protection and influence those who receive the 
GROUP, GRPNAM, and GRPPRV privileges. First, you may want to map 
out the functions you expect your users to perform. Look for groups of 
users involved with a common function, such as accounting, engineering, 
marketing, and personnel. 


Think ahead to future plans in your organization. Incorporate these ideas 
into your strategy. You can fine tune the group design at any time, but it 
is most important to gain a perspective on the logical groupings according 
to the functions your users perform. 


The following example illustrates many principles of group design. The 
Rainbow Paint Company is a distribution company with five departments: 
executive, accounting, marketing, shipping, and secretarial. Table 5-1 
identifies the employees in those departments who need computer 
resources, and their job responsibilities. 


Table 5-1 Employee Grouping by Department and Function 


Department Employee Function 
EXECUTIVE Sunny Gold President 

Olive Green Treasurer 

Head of Computer Operations 

ACCOUNTING Lily White Payroll 

Rich Silver Bookkeeping 

Red Orange Clerk 

Ruby Crimson Clerk 
MARKETING Rusty Brown Forecasting 

Tawny Copper Sales Reporting 
SHIPPING Sky Blue Inventory Control 
SECRETARIAL Misty Grey Correspondence Management 


Paycheck Printing 


The fact that the company has been organized into departments suggests 
that individuals in the same department perform many of the same 
functions. For example, the advantage of grouping all the employees who 
“keep the books” for the company in the accounting department is that 
employees can easily gain access to one another and to the data they must 
share. 


As the system manager of Rainbow Paint’s computer resources, Olive 
Green will set up UIC groups based on the existing organizational 
structure. For example, the employees in the accounting department 

(L. White, R. Silver, R. Orange, and R. Crimson) could be members of the 
UIC group ACCOUNTING. Setting up the UIC group in this way ensures 
that user L. White has easy access to data from user R. Silver, and so 
forth. 
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Effective department organization ensures thai oniy seiected empioyees 
will have access to all data and employees in the company. For example, 
one of the functions of the accounting department concerns payroll. 
Because payroll information is confidential, employees in the shipping 
and marketing departments should not have access to that information. 


Following are two guidelines for determining the placement of users in 
UIC groups: 


e Sharing—Users who typically share data and control of processes 
should be arranged in the same group. 


e Protection—Users who should not have access to each other’s data or 
control each other’s processes should be assigned to separate groups. 


As the system manager of Rainbow Paint’s computer resources, Olive 

sets up the UIC groups ACCOUNTING, EXECUTIVE, MARKETING, 
SHIPPING, and SECRETARIAL corresponding to the various departments 
in the company. Members of a UIC group can be given common access to 
files, as shown in the following example: 


$ SET PROTECTION=G:RWE GROUP_STATS.DAT 


In this command, the owner of the file GROUP_STATS.DAT allows each 
member of the UIC group READ, WRITE, and EXECUTE access to the 
file. 


However, there are limitations to UIC group design. You may want to give 
only a few members of your UIC group access to files that you own, or you 
may want to grant access to your files to members of several UIC groups 
without having to grant world access. These limitations are described in 
the next section. 


5.2.1.1 Limitations to UIC Group Design 
In some cases, UIC-based protection does not present the best solution 
to your file protection needs. If users in several UIC groups need access 
to common files on the system, the only UIC-based alternatives are to 
give world access to the object (all users can access the object) or to grant 
extended privileges to each user. Neither choice is desirable. 


You may also need to allow users in a UIC group several types of access 
to files; you may want to deny some users in the same group access to the 
object. Again, UIC-based protection does not offer a good solution to meet 
these needs. 


Access control lists (ACLs), described in the following sections, offer an 
alternative means of protecting files and other objects on the system. 


9.2.2 Introduction to ACL Design and Identifiers 


Rather than attempting to restructure UIC groups to solve file protection 
problems, you may be able to achieve your goals by using access control 
lists on the files. For example, consider the ACL that you might construct 
to allow specific users (across various UIC groups) to access the file 
PAYROLL.DAT: 
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(IDENTIFIER=OGREEN,ACCESS=READ+WRITE+EXECUTE+DELETE) 
(IDENTIFIER=LWHITE,ACCESS=READ+WRITE+EXECUTE+DELETE) 
(IDENTIFIER=RSILVER,ACCESS=READ+WRITE+EXECUTE+DELETE) 
(IDENTIFIER=MGREY,ACCESS=READ) 
(IDENTIFIER=SGOLD,ACCESS=READ) 


Notice that many of the users share the same access needs. To shorten the 
ACL, you could use AUTHORIZE to define a general identifier PAYROLL 
in the rights database. The holders of that identifier could be all users 
who need RWED access to PAYROLL.DAT. Once the identifier and its 
holders are defined, you could use the following ACL to specify the same 
type of access to PAYROLL.DAT: 


(IDENTIFIER=PAYROLL,AACCESS=READ+WRITE+EXECUTE+DELETE) 
(IDENTIFIER=MGREY,ACCESS=READ) 
(IDENTIFIER=SGOLD,ACCESS=READ) 


The VMS operating system processes shorter ACLs more rapidly. Also, 
when employees change but the functions remain the same, you do not 
have to change every ACL across the system. Instead, remove the user’s 
UAF record; as a consequence, that user also no longer holds the identifier. 
When a new employee is hired for the same job, grant the new user the 
right to hold the identifier. The new user then has the same ACL-based 
access as the former user. 


What you want most of all is an overall design that considers the types 

of files on your system and the protection needs of each. If you have 
successfully designated groups and identifiers, you should be able to easily 
design ACLs and define standard protection. Time spent clarifying the 
common access needs of your users simplifies the design of identifiers and 
ACLs. You will also simplify the job for your users who place ACLs on 
their files. 


Do not use ACLs indiscriminately. They can consume large amounts of 
paged system dynamic memory when files are open. They may also require 
additional processing time. ACLs are best applied where protection is 
really needed. 


For more information on defining identifiers, see the description of the 
VMS Authorize Utility in the VMS Authorize Utility Manual. For more 
information about creating and maintaining ACLs, see the VMS ACL 
Editor description in the VMS Access Control List Editor Manual. 


5.2.3 Some Special-Purpose Identifiers 


The system provides a group of reserved identifiers: LOCAL, DIALUP, 
REMOTE, INTERACTIVE, NETWORK, and BATCH. These identifiers 
permit you to define a large potential group of users according to their use 
of the system. Typically, these types of identifiers are used in combination 
with other identifiers. For example, the following ACE permits user 
Martin to have RWED access to the object only when logged in from a 
local terminal: 


(IDENTIFIER=MARTIN+LOCAL,ACCESS=READ+WRITE+EXECUTE+DELETE) 
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You can use the reserved system identifiers in ACLs to deny access to an 
entire class of logins. For example, the following ACE denies access to all 
dialup users: 


(IDENTIFIER=DIALUP,ACCESS=NONE) 


5.2.4 Creating and Maintaining a Rights Database 


Once you have designed the names of the identifiers you want on your 
system and composed the set of holders for the identifiers, you must 
use the VMS Authorize Utility to make these associations known 

to the system. These associations are kept in the rights database 
(RIGHTLIST.DAT), which you maintain as you add or remove users 
and identifiers. 


The rights database is initially created for every VMS system at system 
installation and is located in the SYS$SYSTEM directory. At that time it 
contains the names of the reserved system identifiers and one identifier for 
each authorized user. The identifier, called a UIC identifier, is associated 
with the user’s UIC and user name. 


There is also an identifier in the rights database equivalent to each UIC 
group name. When you add a new user as the first member of a new 
UIC group, and you specify an account name with the user, an identifier 
corresponding to the account name is added to the rights database, as 
shown in the following example: 


$ SET DEFAULT SYSSSYSTEM 


$ RUN AUTHORIZE 


UAF> ADD ROB/PASSWORD=SP0152/UIC=[014,006] - 

_UAF> /DIRECTORY=WORK: [ROB] /ACCOUNT=MGMT 

UAF~I-ADDMSG, user record successfully added 

UAF-I-RDBADDMSGU, identifier ROB value: [000014,000006] added to RIGHTSLIST.DAT 
UAF-I-RDBADDMSGU, identifier MGMT value: [000014,177777] added to RIGHTSLIST.DAT 


5.2.4.1 


Each site adapts its own rights database according to actual use and 
needs. 


Note that when you use AUTHORIZE to add, remove, or change user 
names in the system UAF, AUTHORIZE makes corresponding changes for 
you in RIGHTSLIST.DAT, so that the rights database corresponds to the 
system UAF. 


You will seldom need to use the AUTHORIZE command CREATE/RIGHTS 
because of the automatic creation and maintenance of the rights database. 
However, if the rights database is damaged or deleted, you can create a 
new one with this command. 


Adding Identifiers 
Add identifiers with the AUTHORIZE command ADD/IDENTIFIER, as 
follows: 


UAF> ADD/IDENTIFIER PAYROLL 
identifier PAYROLL value %X80080011 added to RIGHTSLIST.DAT 
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5.2.4.2 


5.2.4.3 


If you accidentally deleted the rights database, and it cannot be 
recovered from a backup copy, recreate RIGHTSLIST.DAT by entering the 
CREATE/RIGHTS command and then an ADD/IDENTIFIER command, as 
follows: 


UAF> CREATE/RIGHTS 

{message} 

UAF> ADD/IDENTIFIER/USER=* or ADD/IDENTIFIER/USER=[*, *] 
{messages} 


The ADD/AIDENTIFIER command generates a UIC identifier in the rights 
database corresponding to each user name in the UAF. To complete 

the task, use the ADD/IDENTIFIER command to add all general 
identifiers that were lost. Then redefine the holders of the identifiers 
with GRANT/IDENTIFIER commands, as shown in the next section. 


Adding Holders of Identifiers 
Associate users as holders of existing identifiers using the AUTHORIZE 
command GRANT/IDENTIFIER, as shown in the following example: 


UAF> GRANT/IDENTIFIER PAYROLL MARTIN 
UAF-I-GRANTMSG, identifier PAYROLL granted to MARTIN 
UAF> GRANT/IDENTIFIER PAYROLL STEVENS 
UAF-I-GRANTMSG, identifier PAYROLL granted to STEVENS 


To give MARTIN the EXECUTIVE identifier would require another use of 
the GRANT/IDENTIFIER command. You can only introduce one holder 
association at a time with the GRANT/IDENTIFIER command. 


Removing Identifiers and Holders 

When a user leaves the company, remove the UAF record for that user. 
Notify the managers of all sites where that user has access to proxy 
accounts to remove proxy access information in the remotes node’s 
NETPROXY.DAT file. When you run AUTHORIZE to remove a user’s 
UAF record, AUTHORIZE also removes the user’s connections as a holder 
of identifiers in the rights database. However, if a departed user is the 
only remaining holder of a given identifier, remove that identifier to avoid 
future confusion. 


For example, use the following AUTHORIZE command to remove the 
identifier 87TERM3: 


UAF> REMOVE/IDENTIFIER 87TERM3 
{message} 


Before you remove an identifier from the rights database, remove all 
occurrences of the identifier from ACLs on the system. There is no single 
command that displays all uses of an identifier in the ACLs. 


The following example explains how to remove the obsolete identifier 
87SUMMER from the ACL on file TESTPROG.EXE. Invoke the VMS ACL 
Editor to display the contents of the ACL: 


$ EDIT/ACL TESTPROG.EXE 
(IDENTIFIER=STAFF , ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) 
(IDENTIFIER=87 SUMMER, ACCESS=READ+WRITE+EXECUTE) 
(IDENTIFIER=) 


{ 
| 
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The second ACE in the ACL contains the identifier 83/SUMMER. Position 
the cursor at the second ACE and press the PF4 key on the keypad 

to delete the line. Press CTRL/Z to exit the VMS ACL Editor. The 
successfully updated ACL is shown, as follows: 


$ EDIT/ACL TESTPROG.EXE 
(IDENTIFIER=STAFF, ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) 
(IDENTIFIER=) 


%SACLEDIT-S-ACLUPDATED, ACL successfully updated 


$ 


Repeat this procedure for all ACLs containing the identifier 87SUMMER. 
Next, remove the identifier 87SUMMER from the rights database with the 
AUTHORIZE command REMOVE/IDENTIFIER. 


Identifiers in hexadecimal format in an ACE indicate that a general 
identifier has been deleted from the rights database. Similarly, if you see 
an identifier displayed as a numeric UIC, the original identifier was a UIC 
that has been removed. Delete ACEs with numeric UIC or hexadecimal 
identifiers. 


Do not reuse UICs too soon after an employee leaves. The new employee 
may gain some or all of the access rights of the previous employee through 
ACL entries that still reference the old UIC in numeric format. 


To rename an identifier, use the AUTHORIZE command 
RENAME/IDENTIFIER in the following format: 


UAF> RENAME/IDENTIFIER old-identifier new-identifier 


Renaming identifiers affects existing ACLs; those that have ACEs 
specifying renamed identifiers are updated with the new identifier name. 


Displaying the Rights Database 

Security administrators should regularly display the rights database to 
check that it is correct and current. Two AUTHORIZE commands are used 
for this: SHOW/IDENTIFIER and SHOW/RIGHTS. To display all holders 
of an identifier, use the SHOW/IDENTIFIER command, as shown in the 
following example: 


UAF> SHOW/IDENTIFIER/FULL identifier-name 


Use the wildcard asterisk character to display all holders of all identifiers 
on the system, as follows: 


UAF> SHOW/IDENTIFIER/FULL * 


To display the identifiers held by a particular user, use the 
SHOW/RIGHTS command, as shown: 


UAF> SHOW/RIGHTS/USER=username 


Use the wildcard asterisk character to display all identifiers held by all 
users, as follows: 


UAF> SHOW/RIGHTS/USER=* 
UAF> SHOW/RIGHTS/USER=[*,*] 


The first command displays users alphabetically. The second command 
displays users according to UICs. 
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5.2.5 Setting Protection and Ownership Defaults for Users 


If you know that a user will be using a directory or file that demands 
special protection, you must determine which of a number of possible 
protection defaults will affect the user. Exert additional control where the 
default protection is deemed inadequate. Section 4.5 describes default 
protection in detail. There are three possible areas where security 
administrators can specify protection defaults that would affect the user. 
In the order of increasing influence, they are as follows: 


e The systemwide default for file protection provided by the SYSGEN 
parameter RMS_FILEPROT. This value always exists and may be 
the only one to influence the outcome. Security administrators can 
change the value of RMS_FILEPROT with SYSGEN. However, the 
effectiveness of this value may be overridden by either of the following. 


e The DCL command SET PROTECTION/DEFAULT (that can be 
placed in the user’s login command procedure) can specify the 
file protection placed on files created or modified by the user 
during the terminal session. At any time during a session, the 
user can also enter this command to override the value set by 
a previous SET PROTECTION/DEFAULT command. The SET 
PROTECTION/DEFAULT command negates the influence of the 
systemwide protection for this user. 


¢ The default protection for the specific directory can be specified in an 
ACL applied to the directory. If the DEFAULT_PROTECTION ACE 
exists for the directory, all new files added to the directory, including 
subdirectories and their files, are subject to this protection code. This 
code overrides the systemwide default and the user-specified default 
Gf any). 


You may want to include the protection imposed on the volume through 
the DCL command SET VOLUME/PROTECTION. This protection code, 
if specified, prevents a user from accessing any part of the volume, 
regardless of the protection code on the directory or the file. If no volume 
protection is specified with the SET VOLUME command, the volume is 
accessible to all users. 


As Section 4.4 explains, the assignment of file ownership affects the 
outcome of any protection check. The operational effect of this combined 
protection structure is depicted in Figure 5-1. 
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Figure 5—1 (Cont.) Flowchart of File Creation 
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You may want to make adjustments to control default behavior. The 
systemwide default protection code specified by the SYSGEN parameter 
RMS_FILEPROT sets the user’s default protection to: 


(S:RWED,O:RWED,G:RE,W) 

Assume that the volume protection has been set by the operator to: 
(S:RWED,O:RWED,G:R,W) 

The file protection on the directory [PROJECT] has been set to: 
(S:RWED,O:RW,G:R,W) 
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5.2.5.2 


If all the files created in the subdirectory [PROJECT.DIARY] demand more 
protection, you, or any user who has the same access as the owner of the 
directory, could define a specific default protection code for this specific 
directory with an ACL consisting of a DEFAULT_PROTECTION ACE, as 
follows: 


(DEFAULT_PROTECTION,S:RWED,O:RWED,G,W) 
The following DCL command would provide the desired default protection: 
$ SET ACL/ACL= (DEFAULT PROTECTION, S:RWED,O:RWED) [PROJECT]DIARY.DIR 


Once this ACL is placed on the directory file, all files created or modified 
in the directory will be subject to the default protection code. However, 
default protection codes can be easily overridden by any user with the 
BYPASS privilege and can be circumvented under certain circumstances 
by users with SYSPRV, GRPPRV, or READALL privileges. Because they 
are only defaults, a user who acquires CONTROL access to a file in the 
directory can include a specific protection code as a replacement for the 
default value on the file using the following DCL commands: 


¢ SET PROTECTION 
¢ COPY/PROTECTION 
¢ APPEND/PROTECTION 


Once the default protection code is replaced, the new code becomes the 
default and is propagated to subsequent versions of the file. | 


If you provide a special login command procedure for some of your users, 
you may want to supplement the systemwide default process protection 
specified by the SYSGEN parameter RMS_FILEPROT for this group of 
users. Add the SET PROTECTION/DEFAULT to the login command 
procedure to specify the default process protection, as follows: 


SET PROTECTION=(S:RWED,O:RWED,G,W) /DEFAULT 


Files created in the users’ directories receive this default protection code 
unless explicitly overridden. \ 


Setting Up a Project Account 

To allow for more flexible management and accounting of disk space, 
identifiers can carry the optional resource attribute. This attribute, when 
present on an identifier, allows file space to be owned by and charged to 
that identifier. Thus, when a project or department-specific identifier is 
the owner of a directory, the space used by files created in the directory 
can be charged to the appropriate department or project rather than to the 
individual who created them. When users work on multiple projects, they 
can charge their disk space requirements to the related project rather than 
to their personal accounts. 
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To set up a project identifier and directory, perform the following steps: 


1 Create the project identifier with the resource attribute in the rights 
database. The following example creates the identifier PROJECTX: 


$ RUN SYSSSYSTEM: AUTHORIZE 
UAF> ADD/IDENTIFIER PROJECTX /ATTRIBUTES=RESOURCE 


2 Grant the identifier to the appropriate individuals with the resource 
attribute. 


UAF> GRANT/IDENTIFIER PROJECTX useri /ATTRIBUTES=RESOURCE 
UAF> GRANT/IDENTIFIER PROJECTX user2 /ATTRIBUTES=RESOURCE 


3 Create the disk quota authorization for the project identifier. 
For example, the following command invokes the VMS System 
Management (SYSMAN) Utility and assigns the identifier PROJECTX 
2000 blocks of disk quota with 200 blocks of overdraft: 


$ RUN SYSSSYSTEM: SYSMAN 
SYSMAN> DISKQUOTA ADD PROJECTX /PERMQUOTA=2000 /OVERDRAFT=200 


4 Create the project directory. For example, the following DCL command 
creates the project directory [PROJECTX] and establishes the 
identifier PROJECTX as the owner: 


$ CREATE/DIRECTORY [PROJECTX] /OWNER=[PROJECTX] 


5 Set up the necessary ACL on the project directory to allow holders of 
the PROJECTX identifier access to the directory. For example, the 
following DCL command places an ACL on the directory [PROJECTX] 
that permits any holder of the identifier PROJECTX to gain READ, 
WRITE, or EXECUTE access to the directory. The second ACE 
specifies that files created in the directory will receive the same ACE 
as a default. 

§ SET DIRECTORY [PROJECTX] /ACL= (- 


_$ (IDENTIFIER=PROJECTX, ACCESS=READ+WRITE+EXECUTE) , - 
_$ (IDENTIFIER=PROJECTX, OPTIONS=DEFAULT, ACCESS=READ+WRITE+EXECUTE) ) 


Access must be granted through ACL entries, since the owner identifier 
of the directory and the files does not match the UIC of any of the project 
members; thus, only SYSTEM and WORLD access are available through 
the UIC-based protection mask. The first ACE of the specified ACL 

gives all project members READ, WRITE, and EXECUTE access to the 
directory; the second ACE gives the same access for all files created in the 
directory. (The DEFAULT option in the second ACE specifies that the ACE 
is to be copied to each file created in the directory.) 


Note that project members are not allowed to delete (or control) files 
created by others. However, the members each have complete access to 
files they have created in the directory, because the file system supplies 
an additional ACE that grants the file creator CONTROL access plus the 
access specified in the OWNER field of the UIC-based protection mask. 
(The flowchart in Figure 5-1 illustrates how the OWNER field is derived.) 
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This ACE only appears when the owner of the created file does not match 
the UIC of the creator, as is the case for files created in an account owned 
by a project identifier. 


Thus, when project member CRANDALL creates files in the [PROJECTX] 
directory, the files receive the following access control list: 


(IDENTIFIER=CRANDALL,OPTIONS=NOPROPAGATE,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) 
(IDENTIFIER=PROJECTX,ACCESS=READ+EXECUTE) 


This example assumes that the OWNER field grants full (RWED) access. 
Because this may not always be true (the systemwide default set by the 
SYSGEN parameter RMS_FILEPROT may have been changed, or a user 
may have specified a process-specific default protection mask with the 
DCL command SET PROTECTION/DEFAULT), you may want to ensure 
consistency by providing a default protection ACE in the project directory 
ACL, as follows: 


$ SET DIRECTORY [PROJECTX] /ACL= (- 

_$ (DEFAULT PROTECTION, S: RWED,O:RWED,G,W),- 

_$ (IDENTIFIER=PROJECTX, ACCESS=READ+EXECUTE) , ~ 

_$ (IDENTIFIER=PROJECTX, OPTIONS=DEFAULT, ACCESS=READ+EXECUTE) ) 


The UIC protection specified in the default protection ACE is applied to all 
files created in the project directory. 


5.2.6 Password Management 
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A site needing average security protection always requires use of 
passwords. Sites with more security needs frequently impose a generated 
password scheme (see Section 5.2.6.5), and possibly system passwords as 
well. 


This section describes password management. 


Initial Passwords 

When you open an account for a new user with AUTHORIZE, you must 
give the user a user name and an initial password. When you assign 
temporary initial passwords, observe all guidelines recommended in 
Section 3.1.3.10. You may want to use the automatic password generator. 
Avoid any obvious pattern when assigning passwords. 


To use the automatic password generator while using the VMS Authorize 
Utility to open an account, add the /(GENERATE_PASSWORD qualifier 

to either the ADD or COPY command. The system responds by offering 
you a list of automatically generated password choices. Select one of these 
passwords, and continue setting up the account. 


When you add a new user to the UAF, you may want to define that user’s 
password as having expired previously using the AUTHORIZE qualifier 
/PWDEXPIRED. This forces the user to change the initial password when 
first logging in. The system behaves just as if the password had reached 
its expiration date, as described in Section 5.2.6.4. 


5.2.6.2 
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Pre-exnired nasswords are consnicnous in the DAF record listing. The 


entry for the date of the last password change carries the following 
notation: 


(pre-expired) 


By default, VMS forces new users to change their password the first time 
they log in. Include the first login as part of your user training. 


System Passwords 

Section 3.1.3.1 introduces system passwords, which control access to 
particular terminals. System passwords are used to control access to 
terminals that might be targets for unauthorized use, as follows: 


¢ All terminals using dialup lines or public data networks for access 


e Terminals on lines that are publicly accessible and not tightly secured, 
such as those at computer laboratories at universities 


e Terminals not frequently inspected 
e¢ Terminals intended for use only as spare devices 


¢ ‘Terminals the security administrator wants to reserve for security 
operations 


Implementing system passwords is a two-stage operation involving 

the DCL commands SET TERMINAL and SET PASSWORD. 

First, you must decide which terminals require system passwords. 

Then, for each terminal, you enter the DCL command SET 
TERMINAL/SYSPWD/PERMANENT. When you are satisified that 

you have selected the right terminals, incorporate these commands 

in SYS$MANAGER:SYSTARTUP_V5.COM so that the terminal setup 
work is done automatically at system startup time. You can remove the 
restriction on a terminal at any time by invoking the DCL command SET 
TERMINAL/NOSYSPWD/PERMANENT for that terminal. 


Then choose a system password and implement it with the DCL command 
SET PASSWORD/SYSTEM, which requires the SECURITY privilege. This 
command will prompt you for the password and then ask you to reenter it 
for verification, just as is done for user passwords. To request automatic 
password generation, include the (GENERATE qualifier. 


To enable the use of the system password for the remote class of logins 
(those accomplished through the DCL command SET HOST), set the 
appropriate bit in the default terminal characteristics parameter using 
SYSGEN. This is bit 19 (hexadecimal value 80000) in the parameter 
TTY_DEFCHAR2. Note that if you set this bit, you must invoke the 
DCL command SET TERMINAL/NOSYSPWD/PERMANENT to disable 
system passwords for each terminal where you do not want the feature. 
(As before, consider placing the SET TERMINAL commands you have 
tested in SYS$MANAGER:SYSTARTUP_V5.COM.) Follow the steps in the 
preceding paragraph to set the system password. 
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5.2.6.3 


When choosing a system password, follow the recommendations of 
Section 3.1.3.10. Choose a non-English string of characters and digits, 
with a minimum length of 6. The system password is not subject to 
expiration. Change the password frequently. Always change the system 
password as soon as a person who knows the password leaves. Share the 
system password only with those who need to know. 


The system password is stored in a separate UAF record and cannot be 
displayed. The DCL command SET PASSWORD/SYSTEM (the normal 
means of setting and changing the system password) requires that you 
enter the old system password prior to changing it. Use the AUTHORIZE 
command MODIFY/SYSTEM_PASSWORD to change the system password 
without having to specify the old password, as shown in the following 
command: 


UAF> MODIFY/SYSTEM_PASSWORD=ABRACADABRA 


The primary function of the system password is to form a first line of 
defense for publicly accessible ports and to prevent potential intruders 
from learning the identity of the system. However, requiring system 
passwords can appear unfriendly when authorized users are unaware that 
they are required on certain terminals. To avoid false reports of defective 
terminals or systems, inform your users which terminals allocated for 
their use require system passwords. 


Where system passwords are not applied to either control access through 
dialup lines or on publicly accessed lines, few people might know the 
system password. There is the possibility of encumbered operations if the 
personnel who know the password are unavailable, incapacitated, or forget 
the password. Solve this problem by invoking AUTHORIZE and entering 
the MODIFY/SYSTEM_PASSWORD command. SYSPRV privilege is 
required. 


Primary and Secondary Passwords 

The use of dual passwords is cumbersome and mainly warranted at sites 
with high-level security concerns. Dual passwords offer three advantages: 
when used on a widespread basis, they facilitate the verification of the 
physical identity of each user at login time through visual contact; when 
used in limited cases, they single out accounts that can only be logged in 
to when two persons are present; they also prevent accounts from being 
accessed through DECnet using access control strings. 


Sites with medium security requirements might want to use dual 
passwords as a tool when there are unexplained break-ins after the 
password has been changed and the use of the password generator has 
been enforced. Select problem accounts, and make them a temporary 
target of this restriction. If the problem goes away when you institute 
personal verification through the secondary password, you know you have 
a personnel problem. Most likely, the authorized user is revealing the 
password for the account to one or more other users who are abusing the 
account. 


5.2.6.4 


Note: 
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Implement dual passwords with the AUTHORIZE qualifier /PASSWORD. 
For example, to impose dual passwords on a new account, invoke 
AUTHORIZE and enter the following command: 


UAF> ADD newusername /PASSWORD=(primarypwd, secondarypwd) 


To impose a secondary password on an existing account, enter the 
following command: 


UAF> MODIFY username /PASSWORD=("", secondarypwd) 


This command does not affect the primary password that already exists 
for the account, but adds the requirement that a secondary password 

be provided at each subsequent login. The secondary password acquires 
the same password lifetime and minimum length values in effect for the 
primary password. If the /FLAGS=GENPWD qualifier has been specified 
for this account, the secondary password can be changed only under the 
control of the automatic password generator. 


While secondary passwords can be specified for accounts requiring 
remote access using the DCL command SET HOST, they cannot 

be specified for accounts requiring network file access using 
access control strings. Do not specify secondary passwords on 
accounts that require network access, or request remote security 
administrators to set up proxy accounts for those users requiring 
file access to other nodes in the network. 


Enforcing Minimum Password Standards 

Security administrators can use AUTHORIZE to impose minimum 
password standards for individual users. Specifically, qualifiers and login 
flags provided by AUTHORIZE control the minimum password length, 
how soon passwords will expire, and whether the user is forced to change 
passwords at expiration. 


Password Expiration 


With the AUTHORIZE qualifier /PWDLIFETIME, you can establish the 
maximum length of time that can elapse between password changes 
before the user will be forced to change the password or lose access to 
the account. By default, the value of /(PWDLIFETIME is 90 days. You 
can change the frequency requirements for user password changes by 
specifying a different delta time value for the qualifier. For example, to 
require a user to change the password every 30 days, you would specify 
the qualifier as /PWDLIFETIME=30-0. 


The /PWDLIFETIME qualifier applies to both primary and secondary 
user passwords, but not to the system password. Each primary and 
secondary password for a user is subject to the same maximum lifetime. 
However, the passwords can change at separate times. As soon as the user 
completes a password change, that individual password’s clock is reset; the 
new password value can exist unchanged for the length of time dictated by 
/PWDLIFETIME. 
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Note: 


The Authorize Utility also provides two login flags related to primary and 
secondary password expiration. These flags, PWD_EXPIRED and 
PWD2_EXPIRED, are specified with the /FLAGS qualifier. The first 
flag, PWD_EXPIRED, is set on after the primary password expires and 
the user has had one last chance to change the password and failed to 
do so. The second flag, PWD2_EXPIRED, is set on after the secondary 
password expires, and the user has had one last chance to change the 
secondary password and failed to do so. If either PWD_EXPIRED or 
PWD2_EXPIRED is set, the account will be disabled for logins, since the 
user failed to employ the last chance to change the password during the 
last login. 


As soon as the user successfully changes the password, VMS resets 

the flags, as appropriate. The flag PWD_EXPIRED becomes NOPWD._ 
EXPIRED as soon as the primary password is changed. Similarly, the flag 
PWD2_EXPIRED becomes NOPWD2_EXPIRED as soon as the secondary 
password is changed. As security administrator, you may choose to invoke 
AUTHORIZE and reset the flags, giving the user another chance to reset 
the password. 


The use of a password lifetime forces the user to change the password 
regularly. The lifetime can be different for different users. Users with 
access to critical files generally should have the shortest password 
lifetimes. 


System passwords have an unlimited lifetime. Therefore, change the ( 
system password regularly. 


Forcing Expired Password Changes 


By default, users are forced to change expired passwords when logging 
in. Users whose passwords have expired are prompted for new passwords 
at login. This password feature is only valid when a password expiration 
date is specified with the /(PWDLIFETIME qualifier. 


To disable forced password changes, specify the following qualifier to the 
ADD or MODIFY command: \ 


/FLAGS=DISFORCE_PWD_CHANGE 


N 


Once disabled, the forced password feature can be reenabled by clearing 
the login flag, as shown in the following example: 


/FLAGS=NODISFORCE_PWD_CHANGE 


Users who log in and are prompted to change expired passwords can abort 
the login by pressing CTRL/Y. 


If secondary passwords are in effect and both primary and 
secondary passwords have expired, the user is forced to change 
both passwords. If the user changes the primary password and 
presses CTRL/Y before changing the secondary password, the user 
is logged out, and no password change is recorded. 
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Minimum Password Length 


With the AUTHORIZE qualifier /PWDMINIMUM, you can direct that 
all password choices must be a minimum number of characters in 
length. Users can still specify passwords up to the maximum length of 
31 characters. 


This length applies both to primary and secondary passwords and is only 
required when users change passwords with the DCL command SET 
PASSWORD. As security administrator, you can specify initial passwords 
through AUTHORIZE that are shorter than the minimum. However, 
doing so may confuse your users unnecessarily. Furthermore, initial 
passwords inherently introduce security weaknesses. By selecting short 
initial passwords, you compound the problem. Generally, it is good practice 
to observe the same rules you expect your users to follow. 


There is always a minimum password length in effect for each user. 

It is either the default of 6 or another value established by the 
/PWDMINIMUM qualifier. Thus, if the user specifies the DCL command 
SET PASSWORD/GENERATE=n to automatically generate new password 
choices, n must be a value at least as great as the minimum value in 
effect. If n is less than the current minimum enforced in the UAF, it is 
disregarded; no message appears. The five password choices that VMS 
generates for the user comply with the current minimum password length. 


The password generator creates passwords that range in length between 
n and n+2, where n is the specified or minimum length. In addition, 
the maximum values for n and n+2 that the password generator can 
accommodate are 10 and 12, respectively. Longer passwords require an 
inordinate amount of CPU time to generate. 


The system password is not subject to a minimum length. Guidelines 
that apply to user passwords are equally applicable to system passwords. 
Choose system passwords that are 8 to 10 characters long. 


Requiring the Password Generator 

The /FLAGS=GENPWD qualifier in AUTHORIZE allows you to force use 
of the automatic password generator when a user changes a password. At 
some sites, all accounts will be created with this qualifier. At other sites, 
the security administrator may be more selective. 


Criteria for requiring use of the password generator should be whether 
or not the user will have access to sensitive data that must not be 
compromised by a break-in. 


If your policy is to request voluntary use of the password generator, 
and users are not cooperating, you can force users to use the password 
generator by adding the /FLAGS=GENPWD qualifier to most or 

all user accounts. You can also add the AUTHORIZE qualifier 
/FLAGS=LOCKPWD to user accounts to prevent users from changing 
passwords. Only you as system manager will be authorized to change 
passwords. 
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5.2.6.6 


Protecting Passwords 

In addition to all the recommendations included in Section 3.1.3.10, the 
security administrator should observe the following guidelines to protect 
passwords: 


e Make certain the passwords on the standard accounts SYSTEM, 
FIELD, and SYSTEST are secure and changed regularly, or disable 
the accounts with the AUTHORIZE qualifier /FLAGS=DISUSER when 
they are not in use. 


¢ Do not permit an outside or in-house service organization to dictate 
the password for an account they use to service your system. Such 
service groups tend to use the same password on all systems, and their 
accounts are usually privileged. On seldom-used accounts, set the 
AUTHORIZE flag DISUSER, and only enable the account when it is 
needed. You can also change the password immediately after each use, 
and notify the service group of the new password when they need it 
next. 


¢ Delete accounts no longer in use. 
¢ Do not leave listings where they could be read or stolen. 


¢ Maintain adequate protection of authorization files. Note that the 
system user authorization file (SYSUAF.DAT) and network proxy 
authorization file (NETPROXY.DAT) are owned by the system account 
(ISYSTEM]). Do not create any other user accounts in this group. 
Normally the default UIC-based file protection for these authorization 
files is adequate. (You might use ACLs on the listing files SYSUAF.LIS 
and NETPROXY.LIS to grant access only to selected individuals.) 


Following are actions not strictly for password protection, but that reduce 
the potential of password detection or limit the extent of the damage if 
passwords are discovered or bypassed: 


e Avoid giving multiple users access to the same account. 
e Protect telephone numbers for dialup lines connected to your system. \ 


e If your system has accounts available to outside users, such as 
guest accounts or Quality Assurance Reporting accounts, make 
these accounts captive (limited-access) accounts contained by captive 
command procedures. (See Section 5.8 for information about setting 
up captive accounts.) 


e Make all accounts that do not require a password captive accounts. 
e Extend privileges to users carefully. 


e Protect your own files using all the techniques recommended in 
Section 4.9. 


e Ensure that the files containing components of the operating system 
are adequately protected (see Appendix C). 


¢ Use the AUTHORIZE qualifiers /NOINTERACTIVE and /NOBATCH 
when setting up proxy login accounts to only permit file access from ( 
other nodes. Interactive and batch logins are disabled for the account. 
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Login Options 
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This section describes how you can control the display of various pieces of 
information that appear by default at login time, such as announcement, 
welcome, last login, and new mail messages. In addition, this section 
describes the use of the secure server and how to set up break-in detection 
and evasion. 


Controlling the Announcement Message 

Define the system logical name SYS$SANNOUNCE in the site-specific 
startup command procedure SYS$MANAGER:SYSTARTUP_V5.COM to 
provide an announcement message on your system. The Guide to Setting 
Up a VMS System describes how to do this. The announcement message 
appears at login. 


The definition you provide here affects all users on the system. Because 
this message may provide a clue to the identity of the operating system, 
you may decide not to display it. 


Controlling the Welcome Message 

Similar to the announcement message, the welcome message is controlled 
through a system logical name, SYS$WELCOME. If you do not define 
SYS$WELCOME, a standard welcome message is provided for all users. 
This welcome message reveals the operating system and version number, 
as well as the node, if SYS$NODE is defined. 


If you prefer to write your own message, you can define another message 
for SYS$WELCOME. To disable the welcome message, place the following 
DCL command in SYS$MANAGER:SYSTARTUP_V5.COM. This command 
prints a blank line in place of the standard welcome message. 


$ DEFINE/SYSTEM SYSSWELCOME " " 
(See the Guide to Setting Up a VMS System for details.) 


If you prefer to selectively disable the message for individual users, you 
can use the AUTHORIZE qualifier /FLAGS=DISWELCOME on individual 
UAF records. 


Controlling the Last Login Messages 

You can selectively disable the appearance of the series of three messages 
that detail information regarding last logins and number of failed attempts 
at logging in. Enter the /FLAGS=DISREPORT qualifier provided with 
AUTHORIZE for specific users. 


Controlling New Mail Announcements 

You can prevent users from receiving notification that they received new 
mail since the last time they were logged in by specifying the AUTHORIZE 
qualifier /FLAGS=DISNEWMAIL. Because this has no impact on security, 
it is primarily a user convenience. If a user cannot invoke the VMS Mail 
Utility (usually applies to captive accounts), there is no need for that user 
to be notified of new mail. Thus, when you decide to prohibit mail access 
for a user, you might want to disable the new mail message at the same 
time. The following AUTHORIZE qualifier accomplishes both tasks: 


/FLAGS=(DISMAIL, DISNEWMAIL) 
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Controlling Disconnected Processes 

Virtual terminals allow users to maintain more than one disconnected 
process at a time. You may want to restrict the use of virtual terminals. 
For example, if you become concerned about limited nonpaged pool, you 
may not want to enable this feature on a systemwide basis. 


Virtual terminals can be disabled at the terminal or user level. To 
prevent particular terminals from being used as virtual terminals, use 
the DCL command SET TERMINAL/PERMANENT/DISCONNECT. To 
prevent specific users from attaching to disconnected processes, set the 
AUTHORIZE qualifier /FLAGS=DISRECONNECT for those users. (An 
applications account used by multiple users is a good candidate for the 
DISRECONNECT flag to prevent the users from connecting to each other’s 
processes.) 


At the system level, you can disable virtual terminals on a systemwide 
basis with the SYSGEN parameter TTY_DEFCHAR2. However, this has 
other effects as well. You can also set the amount of time allowed for 
reconnection to less than the default of 15 minutes. Use the SYSGEN 
parameter TTY_TIMEOUT for this purpose, and the result also affects 
the system at large. Limiting the connection time tends to minimize the 
number of users who receive messages, but it also affects the usefulness of 
the connection feature. 


Controlling the Number of Retries on Dialups 

You can control the number of login attempts the user is allowed through 
a dialup line. If the user makes a typing mistake after obtaining the 
connection, the user does not automatically lose the connection. This 
option is useful for authorized users, while still restricting the number of 
unauthorized attempts. 


To implement control of retries, use two of the LGI parameters provided 
with SYSGEN (see the VMS System Generation Utility Manual), 
LGI_RETRY_TMO and LGI_LRETRY_LIM. If you do not change the 
parameters, the default values allow the users three retries with a 
20-second interval between each. This means that users will lose the 
connection only if they fail to specify a valid password in three tries, or 
they spend more than 20 seconds between two of their tries. 


Note that these values apply to every user on the system who is permitted 
to access the system through a dialup line. 


The following example illustrates setting the total number of retry 
attempts to six, allowing a half-minute interval between tries. Since these 
LGI parameters are dynamic, you could change them and test them before 
performing the SYSGEN command WRITE CURRENT and rebooting the 
system. 


$ RUN SYSSSYSTEM: SYSGEN 
SYSGEN> SET LGI_RETRY_LIM 6 
SYSGEN> SET LGI_RETRY_TMO 30 
SYSGEN> WRITE ACTIVE 


{OPCOM messages show modification has been made} 


SYSGEN> EXIT 
$ 
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Controlling Break-In Detection and Evasion 

Section 5.2.7.6 shows how to control the number of login retries for users 
dialing in. By limiting the number of retries to a reasonable number 

on each dialup login, you make the job of dialing up and trying every 
password combination more difficult for probing outsiders. This is 
insufficient to completely evade break-ins. First, an obstacle like redialing 
is not going to prove an effective deterrent. Second, this technique applies 
only to dialups. 


The VMS operating system offers additional methods of discouraging 
break-in attempts. These methods also use SYSGEN parameters in the 
LGI category. One of the parameters (LGI_BRK_LIM) defines a threshold 
count for login failures. When the count of login failures exceeds the 
LGI_BRK_LIM value within a reasonable time interval, the system 
assumes a break-in is in progress. Only login failures caused by specifying 
invalid passwords are counted, and they must be from a specific source. 
That source can be any of the following combinations: 


e A specific terminal and a specific valid user name. As described in 
a following section, you can override this default to count failures by 
user name only. Attempted logins using invalid user names never 
trigger break-in detection; however, they are counted together as a 
single class per terminal and are used to trigger security alarms. (See 
Chapter 6 for information about security alarms.) 


e A specific remote node and a specific remote user name. 


e The user name of the creator of a detached process. 


By default, LGI_LBRK_LIM permits five failed login attempts from one of 
these sources. (Security administrators can adjust the value of 
LGI_BRK_LIM with SYSGEN.) 


The SYSGEN parameter LGI_LBRK_TERM controls the association of 
terminals and user names for counting failures. By default, VMS sets this 
parameter to 1 so that they are tracked together. If you set this parameter 
to 0, the terminal is not included in the association; the failures associate 
on user name only. 


Another key parameter, LGI_BRK_TMO, controls the time period in which 
login failures are detected and recorded. The initial failure on each source 
is given an expiration time that represents the current time plus the delta 
time given by LGI_BRK_TMO. Each additional failure on that source adds 
another delta of LGI_BRK_TMO to that entry, thus extending the length 
of time that break in detection is in effect. The cumulative effect is that 
the more failures made by a source, the greater the window of time in 
which additional failures will count toward the critical number defined by 
LGI_BRK_LIM. If no more failures occur by the time the expiration point 
is reached, all failures are forgiven for that source. Note, however, that 
the failure count is not reset by a successful login. 


For example, assume the default values are in effect. LGI_BRK_LIM 
specifies no more than five login failures from one source. LGI_BRK_TMO 
is set for five minutes. Assume that an outsider starts sending user names 
and passwords to the system. When the first password fails, the clock 
starts to run and the user has four more tries in the next five minutes. 
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When the second attempt fails about 30 seconds later, the user has three 
tries left that will be counted over the next 9.5 minutes. When the third 
attempt fails 30 seconds later, the login failure observation time extends 
to 14 minutes. The fourth failure occurs about one minute later; the fifth 
failure occurs within another 30 seconds. By this time, the observation 
time has reached 22.5 minutes. As a result, the next login failure from 
that source within 22.5 minutes will trigger evasive action. 


The system tolerates an average rate of login failures that is the reciprocal 
of the parameter LGI_LBRK_TMO. For example, if the default value of 
LGI_BRK_TMO (800 seconds, or five minutes) is in effect, the average rate 
of tolerable login failures is one every five minutes. When the rate of login 
failures exceeds the tolerable rate, and the critical number of five failures 
is reached (the default value of LGI_BRK_LIM), the system concludes a 
break-in is in progress and initiates evasive action. 


The system stops accepting logins from the offending source for a period 
of time. When the source is a terminal (when LGI BRK TERM equals 
1), for a period of time no one can log in from that terminal with the user 
name that is under suspicion. (However, other users may log in from 
that terminal.) A remote user triggering break-in evasion is prohibited 
from logging in from that node for a period of time. Consequently, login 
attempts that provide valid user name and password combinations that 
should otherwise succeed are rejected during this interval, but only 
from the presumed intruder at that source. Once the interval elapses, 
operations return to normal. As a result of this form of evasive action, 
outsiders are less likely to learn the correct password by using repetitive 
login attempts. 


The duration of the evasive action is controlled by the LGI_HID_TIM 
parameter. The length of time depends on an additional random number 
(in the range of 1 to 1.5) used as a multiplier. The product of 
LGI_HID_TIM and the random number yields the actual duration of 
evasive action. The formula could be represented as follows: 


Evasion time = LGI_HID TIM * (random number) 


The inclusion of a random amount of time helps obscure the true evasion 
time. An outsider who learned the value of LGI_HID_TIM could not be 
assured that the evasive action would persist for exactly that length of 
time. 


These parameters affect all terminals, users, and nodes that access the 
system. Since they are dynamic, you can reset them without rebooting the 
system. 


If the values of LGI_LBRK_LIM and LGI_BRK_TMO can be learned or 
guessed, the outsider can attempt a system break-in over sufficiently long 
intervals that suspicion is not triggered. The outsider can also change 
terminals, nodes, and user names frequently enough to avoid detection. 
Do not rely on these break-in techniques as the sole means of security on 
your system. 


> iia 


eg 
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The technique of counting failures per terminal and user name raises the 
potential for break-in because the password guess rate for a particular 
user name is multiplied by the number of available terminals. Each 
terminal is counted as a separate source for break-in detection. The 
benefit of this approach, however, is that it sharply reduces the denial 

of service problem that could result from simply counting failures per 
terminal or per user name. A malicious user could disable an entire 
terminal room or user’s account for a period of time if failures are counted 
for each user name alone. 


By setting LGI_BRK_TERM to 0, you can detect attempts more quickly, at 
the expense of increasing the risk of denial of service to legitimate users. 


The SYSGEN parameter LGI_LBRK_DISUSER makes the effects of break- 
in detection more severe. If you set this parameter to 1, VMS sets the 
DISUSER flag in the UAF record for the account where the break-in 
was attempted. Thus, that user name is disabled until you manually 
intervene. However, the service denial effects of this option can be very 
severe. A malicious user can put all known accounts, including yours, 
out of service in a short time. To recover, you must log in on the system 
console where the SYSTEM account is always allowed to log in. 


VMS stores information in the break-in database about login failures 
that originate from a specific source. Use the DCL command SHOW 
INTRUSION to display the contents of the break-in database, as shown in 
the following command: 


Intrusion Type Count Expiration Source 
NETWORK INTRUDER 6 12:27:26.08 BOSTON: : JWILLIAMS 
TERM_USER SUSPECT 3 12:42:09.11 AV34C2/LC-2-10:FORGETFUL 


The information provided in the fields in each entry is as follows: 


Intrusion Class of intrusion. 


Type Severity of intrusion as defined by the threshold count for login 
failures. The SYSGEN parameter, LGI_LBRK_LIM, defines the 
threshold count. 


Count Number of login failures associated with a particular source. 

Expiration Absolute time when VMS stops keeping track of login failure. The 
SYSGEN parameter, LGI_BRK_TMO, controls this time. 

Source Origin of the login failure. 


The information in the break-in database is controlled by the SYSGEN 
parameters in the LGI category. 


Use the DELETE/INTRUSION_RECORD command to remove entries 
from the break-in database: 


$ DELETE/INTRUSION_RECORD BOSTON: : JWILLIAMS 


If the source of the break-in is a local terminal that is connected to a 
terminal server, you must enclose the terminal port name within quotes to 
delete the record from the break-in database, as follows: 


$ DELETE/INTRUSION_RECORD "AV34C2/LC-2-10":FORGETFUL 
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See the VMS DCL Dictionary for additional information about the SHOW 
INTRUSION and DELETEANTRUSION_RECORD commands. 


Using the Secure Server 

Section 3.1.3.8 describes password grabbers as a class of programs 
designed to steal passwords from unsuspecting users who log in to 
terminals left on. The VMS operating system provides a secure terminal 
server that stops any currently executing process prior to the start of a 
login at that terminal. 


Invoke the secure server separately for each terminal with the following 
DCL command: 


$ SET TERMINAL/PERMANENT/SECURE/DISCONNECT device-name 


The user must then press the BREAK key followed by the RETURN key to 
initiate a login. The login proceeds as usual. 


If you apply the secure server to all terminals, you make the login 
procedure consistent throughout the site and avoid possible confusion. 
However, certain applications that may use the terminal as a 
communications line may need to use the BREAK key for their own 
purposes. This would be incompatible with the secure terminal server. 


The secure server feature is also incompatible with autobaud handling. 
However, because autobauding is only necessary on modem terminals 
(switched or dialup terminals), the modem handling on such terminals 
performs the equivalent of secure server functions. For secure operation, ( 
set up the terminal characteristics as follows: 


e For local terminals (direct wired) use the following SET TERMINAL 
qualifiers: 


/NOMODEM/SECURE/DISCONNECT/NOAUTOBAUD 


e For switched terminals (data switch and dialup), use the following 
SET TERMINAL qualifiers: 


/MODEM/AUTOBAUD/NOSECURE/DISCONNECT . 


Specify /DIALUP if the terminal port is accessible through a telephone 
line or the equivalent regardless of the path (direct modem, data switch, 
concentrator, or public data network). 


Always specify /DISCONNECT to ensure against password grabbers. To 
prevent disconnected jobs from filling up your system, set the SYSGEN 
parameter TTY_TIMEOUT to a low timeout value, which determines when 
disconnected processes are deleted. 


If you decide to apply the secure server to individual terminals, include 
directly wired terminals located in public areas or remote, unsecured 
areas. Terminals never used for local or dialup logins are not subject to 
this security problem. Terminals closely supervised during logins may 
also not require this measure. (Remember to put the SET TERMINAL 
commands in the site-specific startup command procedure.) 


ec 
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Using the Automatic Login Facility 


You can assign accounts to particular terminals to enable an automatic 
login feature. This feature permits users to log in without specifying 

a user name. VMS associates the user name with the terminal (or 
terminal server port) and maintains these assignments in the file 
SYS$SYSTEM:SYSALF.DAT, referred to as the automatic login file 

cr ALF. Maintain this file with the VMS System Management (SYSMAN) 
Utility commands ALF ADD, ALF REMOVE, and ALF SHOW. 


The ALF consists of one record for each terminal on which automatic 
logins are enabled. Each record consists of two fields: the device name or 
terminal server port name of the terminal, followed by the user name of an 
account. The device names must be unique within the file. However, the 
same user name can occur in any number of records; that is, one account 
can be automatically logged in to an unlimited number of terminals. 


The ALF is an indexed file and does not need to be purged. Back it up 
after a modification. 


Use SYSMAN to add, remove, or display records in the ALF. Invoke 
SYSMAN with the following commands: 


$ RUN SYSSSYSTEM: SYSMAN 
SYSMAN> SET ENVIRONMENT/CLUSTER 
SYSMAN> SET PROFILE/PRIVILEGES=SYSPRV 


The following sections describe the SYSMAN commands you can use to 
maintain the ALF. 


Adding New Records 
Specify the following format of the SYSMAN ALF ADD command to add a 
terminal/user name association in the ALF: 


ALF ADD device-name user-name 


For example, the following command assigns the terminal TTA5 to user 
BHURST: 


SYSMAN> ALF ADD TTA5 BHURST 


If you enter an invalid terminal name, you receive an error message and 
are prompted again. The user name is not checked for validity. 


If a terminal is connected to a terminal server, you must include the port 
name and the /PORT qualifier with the ALF ADD command, as shown in 
the following example: 


SYSMAN> ALF ADD /PORT "MN34C3/LC-1-2" BHURST 


You can include the /LOG qualifier to echo the device name and terminal 
name added to the ALF database. 
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5.2.8.2 


5.2.8.3 


5.2.8.4 


Deleting Records 
Specify the following format of the SYSMAN ALF REMOVE command to 
remove a terminal/user name association in the ALF: 


ALF REMOVE device-name 


For example, the following command removes the record in the ALF for 
terminal TTA3: 


SYSMAN> ALF REMOVE TTA3 


The /USERNAME qualifier allows you to remove records in the ALF by 
user name rather than terminal (or port) name. For example, the following 
command removes all records assigned to user DOUGLAS: 


SYSMAN> ALF REMOVE /USERNAME=DOUGLAS 
You can use wildcard characters with the (USERNAME qualifier. 


Displaying Records 
Use the SYSMAN ALF SHOW command to display one or more records in 
the ALF database, as shown in the following example: 


SYSMAN> ALF SHOW TTAS 


The command in this example displays the user name in the ALF database 
associated with the terminal TTA5. You can also display records in 

the ALF database based on user name by specifying the /USERNAME 
qualifier, as shown in the following example: 


SYSMAN> ALF SHOW /USERNAME=PTROULX 


The command in this example displays all records in the ALF database 
associated with user PTROULX. 


You can specify wildcard characters in the terminal name or port name. 


Specify the /OUTPUT qualifier to direct the output from an ALF SHOW 
command to a file, as shown in the following command: 


SYSMAN> ALF SHOW /OUTPUT=SYSMAN_123189.LIS 


If you do not include a file specification with /OUTPUT, SYSMAN writes 
the output to the file SYSMAN.LIS in your default directory. 


Restricting ALF Users 

To force individuals at specific terminals to log in to an application 
program, create a separate, captive account for the application. With 
ALF, set up automatic logins to the new account for the desired users. 


Logging In te an Automatic Login Terminal 

Once you set up a terminal for automatic login, it can only be used for the 
designated account. This is most useful for applications terminals used by 
persons who may be unfamiliar with computers. Thus, an automatic login 
account will very likely also be a captive account. 


The automatic login feature suppresses the user name prompt. All other 
login features (system password, primary and secondary passwords, and 
messages) function normally, if enabled. 
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Passwords are optional. If you want the account to be open to all users 
where the terminals are located, eliminate the password. When no 
password is required, the user has no data to enter at login. VMS logs the 
terminal in automatically in response to the BREAK key or the RETURN 
key and immediately enters the application if the account is under the 


control of a captive login command procedure. 


Protecting Automatic Login Accounts 

Automatic login accounts are potentially accessible from terminals and 
sources other than the terminals listed in the ALF and, therefore, require 
protection, especially if they have no password, as follows: 


1 Restrict network and dialup access, as appropriate, with the 
AUTHORIZE qualifiers /NODIALUP, /NONETWORK, and 
/NOREMOTE. 


2 Set the AUTOLOGIN flag in the account’s UAF record. This flag 
makes the account available only by autologin, batch, and network 
proxy. 





5.3 Authorizing Usage 


As you authorize users, consider what restrictions should apply to each 
to provide additional control over their use. You can restrict them to 
certain devices, commands, privileges, short account durations, working 
times, and modes of operation (batch, dialup, remote, network, local, or 
interactive). 


5.3.1. Restricting Devices 


5.3.1.1 


There are a number of ways you can restrict the devices available to users. 
You may want to limit use to particular devices, or you may want to limit 
amount of usage. The next sections describe the controls available to you 
for restricting the use of terminals, disk volumes, applications terminals, 
and miscellaneous devices. 


Restricting Terminal Use 

Through the SYSGEN parameters TTY_DEFPROT and TTY_OWNER, 
VMS sets up terminals to be accessible to the SYSTEM account only. 
(Users can log in because login always starts to execute as a system 
process.) To make terminals accessible to certain users as applications 
terminals, you may want to change any or all of the following: 


¢ Protection 

¢ Owner UIC 

e ACLs 

The application of system passwords limits the use of those terminals 
to users who know the system password. You can also include SET 
PROTECTION/DEVICE and SET ACL/OBJECT=DEVICE commands: 


for specific terminals (with appropriate protection codes) in the command 
procedure SYS$MANAGER:SYSTARTUP_V5.COM. 
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5.3.1.3 


Restricting Disk Volumes 

Identify the user’s default device and directory in the UAF record with 
the AUTHORIZE qualifiers /DEVICE and /DIRECTORY. You can limit 
the number of blocks available to the user on that disk (and any other 
disk) through the disk quota feature or the VMS System Management 
(SYSMAN) Utility, as described in the VMS SYSMAN Utility Manual.) 


The volume protection in place on other disks controls how much access a 

user can obtain to the disks. The user’s privileges, which can be extended 

or limited through the AUTHORIZE qualifier /PRIVILEGES, also influence 
the access available (see Section 5.3.6). 


Applications Terminals and Miscellaneous Devices 

Use the DCL command SET PROTECTION/DEVICE to limit access to any 
nonfile-structured device. You might also apply an access control list on 
the device to limit user access. 


5.3.2 Restricting Work Times 
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AUTHORIZE qualifiers allow you to restrict system use to certain periods 
of the day. Define primary and secondary days of the week with the 
/PRIMEDAYS qualifier or conform to the default where primary days are 
Monday through Friday and secondary days are Saturday and Sunday. 
For example, if a user works Tuesday through Saturday, you would specify 
the /PRIMEDAYS qualifier as follows: 


/PRIMEDAYS= (NOMON, TUES, WED, THUR, FRI, SAT, NOSUN) 


Occasionally an operational change occurs that conflicts with the normal 
day assignments at your site, such as a holiday falling on a primary day. 
To override the normal day assignment, use the DCL command SET DAY, 
and specify the day-type interpretation you want for the current day. This 
requires OPER privilege. Note that this change applies to all logged-in 
users, as well as those who will log in during the day. Users who are 
currently logged in who are unauthorized for logins for the day-type once 
it changes will be logged off the system at the next hour. (The VMS Job 
Controller enforces time restrictions on an hourly basis.) 


Decide which types of login access should be restricted to certain 

hours. The login access qualifiers are: /LOCAL, /REMOTE, /DIALUP, 
/INTERACTIVE, /BATCH, and /NETWORK. However, if your site applies 
one set of primary and secondary hours for all types of logins, you can 
specify the /ACCESS qualifier, which applies to all modes of access. 


The following example shows how to apply the /BATCH qualifier to a 
user’s account to disable the user from running batch jobs during normal 
working hours. 


/NOBATCH= (PRIMARY, 9-17) 


This specification permits the user to run batch jobs only during the hours 
of 6:00 p.m through 8:59 a.m. on primary days, but all day on secondary 
days. (Restricting work times is useful to better balance the workload on 
your system.) 


oie 


System Security Implementation 
5.3 Authorizing Usage 


You may want to disable specific accounts used only periodically, such 

as the SYSTEST and FIELD accounts, to limit possible misuse of these 
accounts. Disable the accounts with the qualifier /FLAGS=DISUSER. 
Temporarily enable the accounts with the /FLAGS=NODISUSER qualifier 
when needed. 


5.3.3 Restricting Mode of Operation 


The following concerns might cause you to prohibit network access for 
some of your users: 


e The user has data that should only be accessed through the local node. 


e Penetration attempts are more likely to occur over a network because 
of the increased anonymity of the connection. (This concern is also 
relevant to dialup connections.) 


Use the AUTHORIZE qualifier /NONETWORK to prevent specific users 
from having network access, as shown in the following example: 


UAF> ADD JSMITH /NONETWORK, 


Any of the AUTHORIZE access mode qualifiers (LOCAL, /REMOTE, 
/DIALUP, ANTERACTIVE, /BATCH, or /NETWORK) can be negated in 
this manner to restrict access to the system. 


5.3.4 Restricting DCL Command Usage 


There are several methods that you can apply to affect the use of DCL 
commands by your users. Among them are the following: 


¢ Remove or modify DCL command definitions, and rebuild the DCL 
tables. (The VMS Command Definition Utility Manual describes 
how to create command definitions.) Use the /CLITABLES qualifier 
in the user’s UAF record to specify the modified tables. Specify 
/FLAGS=DEFCLI to ensure that the user can only log in with the 
specified CLI and tables, and protect the original DCL tables from 
unauthorized access. 


¢ Impose ACLs on the system program files in the directories 
SYS$SYSROOT:[SYSEXE] and SYS$SYSROOT:[SYSLIB]. 


5.3.5 Restricting Account Duration 


It is good practice to set an account expiration time that matches the 
maximum length of time you expect the user to require access. When the 
expiration time arrives, the system automatically prohibits access to the 
account. You must still remove the UAF record and delete the user’s files. 


To set the account expiration time, use the AUTHORIZE qualifier 
/EXPIRATION in the user’s UAF record. For example, the following 
qualifier specifies that the user’s account will expire on the 30th of 
December, 1988: 


/EXPIRATION=30-DEC-1988 
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Granting User Privileges 
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Some system activities are limited to users who hold specific privileges. 
These restrictions protect the integrity of the operating system’s 
performance and, thus, the integrity of service provided to users. Grant 
privileges to each user on the basis of two factors: (1) whether the user 
has a legitimate need for the privilege, and (2) whether the user has the 
skill and experience to use the privilege without disrupting the system. 


Privileges are divided into seven categories according to the damage that 
the user possessing them could cause the system: 


¢ None—No privileges 

e Normal—Minimum privileges to effectively use the system 

¢ Group—Potential to interfere with members of the same group 
¢ Devour—Potential to consume noncritical systemwide resources 
e System—Potential to interfere with normal system operation 

e File—Potential to compromise file security 

¢ All—Potential to control the system 


A user cannot execute an image that requires a privilege the user does 
not possess unless the image is installed as a known image with the 
privilege in question. (See the VMS Install Utility Manual for instructions 
on installing known images.) Execution of a known image with privileges 
grants those privileges to the user process executing the image for the 
duration of the image’s execution. Thus, you should install user images 
with amplified privileges only after ensuring that the user needs the access 
and is unlikely to misuse it. 


A user’s privileges are recorded in the user’s UAF record in two privilege 
vectors. One vector stores the authorized privileges, and the other vector 
stores the default privileges. The default privileges are the subset of 
authorized privileges that a user process receives at login. 


When a user logs in to the system, the user’s privilege vector is stored 
in the header of the user’s process. In this way, the user’s privileges are 
passed on to the process created for the user. Users can use the DCL 
command SET PROCESS/PRIVILEGES to enable and disable privileges 
for which they are authorized. A user with the SETPRV privilege can 
enable any privilege. 


Table 5-2 categorizes the privileges and includes a brief definition of the 
powers associated with each privilege. 
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Tabie 5-2 


Category 
None 


Normal 


Group 


Devour 


System 


Files 


All 


Limiting User Privileges 


—_— a. 
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VMS Priviieges 


Privilege 


None 


MOUNT 
NETMBX 
TMPMBX 


GROUP 
GRPPRV 


ACNT 
ALLSPOOL 
BUGCHK 
EXQUOTA 
GRPNAM 
PRMCEB 
PRMGBL 
PRMMBX 
SHMEM 


ALTPRI 
OPER 
PSWAPM 
WORLD 
SECURITY 
SYSLCK 


DIAGNOSE 
SYSGBL 
VOLPRO 


<__ BYPASS - 


CMEXEC 
CMKRNL 


Activity Permitted 


None requiring privileges 


Execute mount volume QiO 
Create network connections 
Create temporary mailbox 


Control processes in the same group 
Group access through SYSTEM protection field 


Disable accounting 

Allocate spooled devices 

Make bugcheck error log entries 

Exceed disk quotas 

Insert group logical names in the name table 
Create/delete permanent common event flag clusters 
Create permanent global sections 

Create permanent mailboxes 

Create/delete structures in shared memory 


Set base priority higher than allotment 
Perform operator functions 

Change process swap mode 

Control any process 

Perform security related functions 
Lock systemwide resources 


Diagnose devices 
Create systemwide global sections 
Override volume protection 


Disregard protection 

Change to executive mode 

Change to kernel mode 

Create detached processes of arbitrary UIC 
Issue logical I/O requests 

Map to specific physical pages 

Issue physical /O requests 

Possess read access to all system objects 
Enable any privilege 

Access devices allocated to other users 

Insert system logical names in the name table 
Access objects through SYSTEM protection field 


Granting privileges allows users those privileges until you remove them. 
To avoid such blanket permission, you may want to grant privileges on an 
as-needed basis. For example, certain users might need to run a program 
requiring any of the more powerful privileges. You could install the 
program with the necessary privilege using the VMS Install Utility. Then 
put an ACL on the executable image file to clearly specify users allowed 
to execute it. The users would effectively possess the privilege only when 
they are actually executing the image. When the image stops running, the 
user no longer holds the privilege. | 
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5.3.6.2 


Note: 


Following is an example of this method. The program SDA.EXE (required 
to analyze system dumps) requires CMKRNL privilege to analyze the 
running system. The security administrator installs SDA.EXE with the 
CMKRNL privilege, .as follows: 


$ RUN SYSSSYSTEM: INSTALL 
SDA.EXE /PRIVILEGED=CMKRNL 
{messages} 


Next, the security administrator places an ACL on SDA.EXE and also sets 
the UIC-based protection to deny all access to the WORLD category of 
users, as follows: 


$ SET ACL/ACL= (IDENTIFIER=SDAUSERS, ACCESS=EXECUTE) - 
_$ SYSSSYSTEM: SDA.EXE 
$ SET PROTECTION=(WORLD) SYSSSYSTEM:SDA.EXE 


Finally, the security administrator uses the AUTHORIZE command 
to confirm that the users who hold the SDAUSERS identifier are 
those intended to run the program. If necessary, the manager makes 
adjustments to this list of users. 


Digital ensures that all system programs (such as SDA) that are supplied 
with VMS are linked with the /NOTRACEBACK qualifier to prevent online 
debugging or traceback. Take the same precaution with your own images. 
Online debugging and traceback are prime sources of security problems. 


All images that you install with privilege must be linked with 
the /NOTRACEBACK qualifier to prevent online debugging and 
traceback. 


Another alternative to granting blanket privileges is to set up emergency 

or specialized privileged accounts. Users would only log in to these 

privileged accounts to perform specific functions. You have two options 

with this technique. First, you establish a limited group who know about 

the account and are informed how to use it. Second, you create two 

accounts for the user, giving the privileges to one account but not to the 

other. In this case, the user would have the same UIC and the same / 
default directory in each account. (This is the only case where Digital \ 
recommends shared UICs, since there is still only one actual user.) If you 
decide to adopt this dual account practice, avoid obvious user names that 
reveal which account is the privileged account. 


With both options, you can place special restrictions on the privileged 
account, such as long passwords, brief password lifetimes, restricted hours, 
and limited modes of operation (no dialup, no network, remote, or batch 
access). Also, limited account durations would force frequent consideration 
of privilege requirements. 


Suggested Privilege Allocations 

Appendix A lists all user privileges and includes recommendations on 
when to grant them. When allocating user privileges, consult Table 5-2. 
Be conservative. . 


5.3.6.3 
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The summary guidelines in Table 5—3 indicate the minimum privilege 
requirements for common classes of system users. 


Table 5-3 Minimum Privileges for System Users 


Type of User Minimum Privileges 
General TMBMBX,NETMBX 
Operator OPER 

Group Manager GROUP,GRPPRV 
System Manager/Administrator SYSPRV,SETPRV 
Security Administrator SETPRV,SECURITY 


Controlling Privileged Accounts 

Since abuse of privileged accounts can result in serious losses, consider 
imposing special controls on accounts with the most powerful privileges 
(except the VMS-supplied SYSTEM account), as follows: 


e Limit access to the account. For example, you can prohibit dialup or 
network access with the /NODIALUP or /NONETWORK qualifiers to 
discourage outsiders from attempting break-ins from remote locations. 


¢ Use the /PRIMEDAYS and /NOACCESS qualifiers to restrict the time 
of day or days of the week that logins can be performed. Select periods 
of time that can be monitored for appropriate use. 


¢ Disable the account when not in use with the AUTHORIZE qualifier 
/FLAGS=DISUSER. 


¢ Use a captive login command procedure for additional validation. 
Captive login command procedures are described in Section 5.8.1. 


¢ Impose security alarms to detect use of the privileges pertaining to 
file protection: BYPASS, SYSPRV, READALL, and GRPPRV. For 
information about setting up and monitoring security alarms, see 
Chapter 6. 


Special Purpose Privileged Captive Accounts 

Although generally unadvisable, it is sometimes necessary to grant 
privileges to captive accounts rather than giving users access to 
unrestricted, privileged accounts. For example, users who perform backup 
operations require the READALL privilege. By making the account that 
performs backups captive, you can ensure that the procedures are carried 
out according to your system’s backup policy. 


Guidelines in setting up captive accounts are provided in Section 5.8. 


Examples of Establishing User Accounts 


This section illustrates the creation of three user accounts with options 
ranging from least to most restrictive. Chapter 8 includes a similar 
example that illustrates a number of principles involved in designing and 
implementing proxy login accounts. 
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5.3.7.1 


The first account represents highly privileged users, such as system 
managers, with minimum restrictions and maximum access to the syste1a. 


The second example illustrates an interactive user account with moderate 
restrictions, typical of an account at a commercial site where security is a 
concern and the average user has limited access. 


The third example depicts an applications production account where the 
user is highly restricted. 


In the following examples, any value not specified defaults to the value 
provided by the DEFAULT record in the UAF. 


A System Manager’s Account 

Example 5-1 illustrates a number of AUTHORIZE qualifiers appropriate 
for a system manager’s account. Notice the use of a short password 
lifetime, the requirement that the automatic password generator be used 
to change passwords, and the use of primary and secondary passwords. 
These measures are important to protect the account because it affords 
many valuable privileges and access rights. 


Example 5-1 A Sample Security/System Manager’s Account 


$ SET DEFAULT SYSSSYSTEM 


$ RUN AUTHORIZE 


UAF> ADD RIRONWOOD/PASSWORD= (VALTERSY, ESTREMAY) /UIC=[001,100] - 
_UAF> /DEVICE=SYSSSYSDEVICE/DIRECTORY=[RIRONWOOD] - 

_UAF> /OWNER="Russ Ironwood"/ACCOUNT=SECURITY/FLAGS=GENPWD - 
_UAF> /PWDLIFETIME=30-/PWDMINIMUM=8 - 

_UAF> /PRIVILEGES=SETPRV 

identifier for value: [000001,000100] added to RIGHTSLIST.DAT 


UAF> 


5.3.7.2 
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This user has the most powerful privilege of all, SETPRV. With this 
privilege the owner can acquire any other privilege. 


A Typical Interactive User’s Account 

Example 5~2 illustrates the creation of an account of a typical interactive 
user. Only one password is required, with a minimum length of 6 
characters. The user’s password is valid for 90 days, a much longer 
lifetime than the manager’s password. The user is allowed access during 
the week and on Saturdays, during a fifteen-hour period. 
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Example 5-2 A Typical Interactive User Account 


$ SET DEFAULT SYSSSYSTEM 

$ RUN AUTHORIZE 

UAF> ADD RDOGWOOD /PASSWORD=TRALAYAM/UIC=[231,010] - 

_UAF> /DEVICE=BOTANYDEV/DIRECTORY=[RDOGWOOD] - 

_UAF> /OWNER="Robert Dogwood"/ACCOUNT=BOTNYDPT - 

_UAF> /FLAGS=(GENPWD) - 

_UAF> /PRIMEDAYS= (MON, TUES, WED, THURS, FRI,SAT,NOSUN) - 

_UAF> /EXP IRATION=15-JUNE-1987/PWDLIFETIME=90-/PWDMINIMUM=6 - 
_UAF> /NOACCESS= (PRIMARY, 23-6, SECONDARY) /NODIALUP 

identifier for value: [000231,000010] added to RIGHTSLIST.DAT 
UAF> 


§.3.7.3 A Production Account 
Example 5-3 illustrates the creation of a production account. This account 
is designed to perform one function: to list the grades at State University 
and to produce mailings to each student’s home. This job can only be 
run from the captive account REPGRADES, and it may not be run over 
dialup lines or as a remote job. Nor will the account permit network 
access. When the job is run through a local login, it is restricted to the 
hours of 8 a.m. through 5:59 p.m., Monday through Friday. However, 
when the job is run in batch mode, it is not restricted to special times. 
The user who initiates the login must specify the password, GROBWACH. 
(Most likely only the security administrator will change the password.) 
The process runs under the control of a special login command procedure 
(GRADES.COM), which presumably provides the operator with a menu of 
functions. (The process is restricted to the commands defined in the CLI 
table, GRADES_TABLES.) 


Example 5-3 A Production Account 





$ SET DEFAULT SYSS$SYSTEM 
$ RUN AUTHORIZE 
UAF> ADD REPGRADES /PASSWORD="GROBWACH"/UIC=[777,031] - 
_UAF> /DEVICE=ADMINDEV/DIRECTORY=[REPGRADES] - 
_UAF> /OWNER="Campus Admin"/ACCOUNT=ADMIN - 
_UAF> /FLAGS= (CAPTIVE, DISWELCOME, DISNEWMAIL,DISMAIL,DEFCLI) - 
_UAF> /LOCAL=(PRIMARY, 8-17) /PRIMEDAYS= (MON, TUES, WED, THU,FRI,NOSAT,NOSUN) - 
_UAF> /NONETWORK/NOREMOTE/NODIALUP - 
_UAF> /LGICMD=GRADES/CLITABLES=GRADES TABLES - 
UAF> 


user record successfully added 
identifier for value: [000777,000031] added to RIGHTSLIST.DAT 





Training the New User 


Teaching new users about system security is an important security tool. It 
is important to involve users in security methods and goals; the more they 
know about the system and how break-ins occur, the better equipped they 
are to guard against them. 
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Following is a list of topics to include in user training: 


What is the location of the user’s account? Specifically, which system, 
where is it located, what is the proper node name if on a network, and 
if the system is part of a cluster, what other nodes are available? 


Which terminals can be used for logging in and where are they located? 


Is the account restricted with regard to local, dialup, remote, 
interactive, network, or batch operations? If so, describe both 
permitted use and restrictions. 


Can the account be accessed by dialing in? If so, provide the access 
telephone number and describe the procedure. Specify how many 
retries are allowed and the maximum number of seconds allowed 
between each before the connection is lost. 


Are system passwords implemented for any terminals that the user 
may be using? If so, describe which terminals, how often the system 
password is changed, and how the user can learn the new system 
password. 


What is the account duration? When will it expire? From whom 
should the user request an extension? 


What is the user name? What identifiers are held by the user, if any? 
What are the group and member numbers associated with the user? 


What password information is required? Specifically, what is the initial 
password? Is the password locked? If the password is not locked, how 
often must the password be changed? What is the minimum length 
for the password? Is there a secondary password for this account, and 
who will know it? Is the user free to select passwords, or must they be 
automatically generated? 


What is the default device and directory? 
What is the default protection? 
Are there quotas on disk usage? If.so, what are the values? 


Are there restrictions on use? For example, are there certain days or 
hours of the day that are suggested or enforced? Explain primary and 
secondary days if applicable. 


Are there files or directories that are shared? If so, provide the details. 


Are there ACLs that affect the user? What identifiers does the user 
need to know? 


Which privileges does the user hold? 
What is the command language interface? 


Which type of account is this—open, locked, captive/restricted, or 
normal? 


Which nodes permit proxy logins for this user, if any? 


What are the names of the queues the user may need to use? 


BIS 
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¢ Describe actions related to the physical aspects of security, such as 
locking up materials. 





5.4 Protecting Information 


After designing an appropriate system access plan, you must address 
which files you want your users to access. Even on the most open system, 
you will want protection for the system software. Digital provides default 
UIC protection for this purpose that is generally sufficient. However, 

you may want to override the default UIC protection or set up ACLs for 
specific system files. Table 5-4 provides a summary of DCL commands you 
use to set up and display file protection. 


Table 5-4 DCL Commands Used to Protect Files 


Command Function 

DIRECTORY/ACL Displays the ACL for the file 

DIRECTORY/OWNER Displays the file owner’s UIC 

DIRECTORY/PROTECTION Displays the file’s protection mask 

DIRECTORY/SECURITY Combines and displays file information produced 
by DIRECTORY/ACL, 
DIRECTORY/OWNER, and 
DIRECTORY/PROTECTION 

EDIT/ACL Invokes the Access Control List (ACL) Editor 

SET ACL Creates, modifies, or deletes access control list 
entries (ACEs) in an ACL 

SET ACL/EDIT Invokes the Access Control List (ACL) Editor 


(synonymous with EDIT/ACL) 
SET DIRECTORY/OWNER_UIC Modifies the owner UIC of the directory 


SET FILE/OWNER_UIC Modifies the owner UIC of the file 

SET FILE/PROTECTION Changes the file’s protection code 

SET PROTECTION Changes the file’s protection code (synonymous 
with SET FILE/PROTECTION) 

SHOW ACL Displays the file’s ACL 


These commands are described in the VMS DCL Dictionary. 


5.4.1. Restricting Command Outputs 


Some DCL commands behave differently depending on the privileges that 
the user holds. 


For example, unless a user holds the GROUP or WORLD privilege, the 
SHOW PROCESS command limits the display of process information 
to the user’s process. A user with GROUP privilege can display other 
processes in the user’s UIC group; a user with WORLD privilege can 
display any process on the system. 
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5.4.2 Protecting System Programs and Databases 


Normally, Digital delivers system programs and databases with adequate 
protection. However, if for any reason you are dissatisfied with the default 
protection, you can change it with the techniques outlined in Chapter 4, 
provided you have the necessary SYSPRV privilege. You might also add an 
ACL to any file that you decide needs additional protection. Appendix C 
presents the recommended protection codes for all system files. Your 
VMS software should have this set of protection codes following a correct 
installation. Examine your system files from time to time to ensure that 
this protection is maintained. 


As indicated, Digital provides default protection for the system programs 
that it provides. However, if you have a special requirement, you might 
examine the potential of ACLs for your needs. For example, you could 
consider using ACLs to restrict the use of system programs such as 
compilers. (Any number of considerations might prompt this action, 
ranging from performance to licensing issues.) 


Another possible question worth investigating is: are there cases 
where you do not want some or all of your users able to initialize 
media? If so, you could put an ACL to good use on the system program 
SYS$SYSTEM:INIT.EXE. You would ensure that you grant no access to 
the WORLD category in the UIC-based protection field. Then create an 
ACL for the file that grants access to the specific users you want. 


Similarly, if a department in your company has paid for a license to a 
software product, you may want to make that software available to them, 
but not to others. You would ensure that the WORLD category receives no 
access through the standard UIC-based protection code and create an ACE 
in the ACL for that file that allows the access through the department’s 
identifier. 


You may also find that ACL protection is relevant to protect your 
applications databases, limiting the access to certain users. 


5.4.3. Precautions to Take When Installing New Software 


When you install new software, you must address several security 
concerns. You want to ensure that you are not admitting software that 
will in any way corrupt or undermine your usual security precautions. 
You must also consider whether or not to install the software with any 
privileges. When you install privileged software, you allow users to 
execute it whether or not they personally possess the required privilege. 
In effect, you extend the privilege to the process while it runs the software. 
While this offers some advantages with clear security implications, it also 
introduces several security-related dangers. This section discusses security 
aspects of installing new software. 
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Protecting Programs and Directories 

New software can contain programs that are potentially harmful to your 
system. These programs, called Trojan horse programs, are designed to do 
damage and frequently include devices that do the following: 


e Pass privileges of the person running the program back to the author 
of the program 


¢ Allow unauthorized access to the system 
¢ Change protection of system files 
e Patch the system (add special software to the operating system) 


¢ Create jobs that scan for easily-guessed passwords 


To protect your system from this type of break-in, always buy software 
from reputable sources. When training new users, stress the importance 
of avoiding use of software from an unknown source. 


Another risk to programs and directories is known as the worm. While 
Trojan horse software must rely on the innocent user to unwittingly accept 
the damaging software by using it, the worm requires no user cooperation. 
It is a program that takes advantage of faulty file protection, working its 
way through your system, modifying command procedures and executable 
programs. By modifying command procedures, it can propagate by making 
use of user access rights and privileges. 


The user’s login command procedure is a prime target for this type of 
security breach. Login command procedures generally contain easily 
modified DCL commands and are executed regularly. 


ACLs are also targets. File protection designed with users sharing 
access privileges allows this type of program to run through many users’ 
programs, acquiring new privileges along the way. 


Well-designed file protection is vital for protection from this type of breach. 
Make sure that likely targets are not modifiable by users. For example, 
set up file protection so that your login command procedure permits only 
READ access to all other users. Also, make sure the directory containing 
the login command procedure permits WRITE access only to users in the 
SYSTEM and OWNER categories. 


Because most damage occurs when programs like these reach a target 
account with privileges, users with privileges should be especially cautious 
when designing file protection. 


Installing Programs with Privilege 

Some software requires privilege to run. You can extend the privilege to 
all users you expect will need to run the software, or install the program 
with the required privileges. Section 5.3.6 describes these options in 
greater detail. 
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5.5 File Encryption 


File encryption refers to the process of applying an algorithm to data 

to conceal its content. Decryption reverses the operation and converts 
encoded information back to its original content. If you needed to copy 
proprietary software onto media for removal to another site, you might use 
file encryption. The software on the media is useless without the correct 
decryption code. 


To perform these tasks, there is a software facility available to VMS users 
as an optional layered product. Consult the VMS Data Encryption Facility 
Manual for more information. 


5.6 Disk Maintenance Considerations 
Proper disk maintainence includes the following: 
e Physical security for disks 
e Backups of disks 
e Physical security for backup media 


¢ How to retrieve files from backups 


Having an effective backup schedule is vital to protect your data. By 
performing regularly-scheduled backup operations, you prevent the loss of 
accidentally deleted or damaged files. Never give a copy of your backup 
media to a user; a malicious user could restore the files from the tape or 
disk and compromise the security of the system. Refer to the VMS Backup 
Utility Manual for information about performing backups and setting up 
backup schedules. 


5.7 Methods for Discouraging Disk Scavenging 


Disk scavenging is the process of reading magnetic imprints of data after 
deletion of the file header following a purge or delete operation. (When 
users delete files from the system, only the file header is deleted.) Until 
the data is overwritten, it is a potential target for disk scavenging. Sites 
with medium or high security needs should be concerned about this 
procedure. 


After establishing overall security features, restrict access to disks 
containing valuable information using UIC-based volume protection. 
Because disk scavenging is frequently performed by authorized users, 
consider implementing erasure patterns and highwater marking, as 
described in the following sections. 


5.7.1. Erasing Techniques 


There are several ways to implement erasing of disks. 


a 
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The inclusion of the /EKASE qualifier with the DELETE or PURG 
commands causes the system to write an erasure pattern of zeros over the 
entire file location when you delete or purge that file. You can encourage 
users to use this qualifier voluntarily, or make inclusion automatic by 
including the following command definitions in the system login command 
procedure (usually SYS$MANAGER:SYLOGIN.COM): 


DEL*ETE :== "DELETE/ERASE" 
PUR*GE :== "PURGE/ERASE" 


Any user can bypass these definitions by adding the /NOERASE qualifier 
to the DELETE or PURGE commands. 


To guarantee erase-on-delete, turn on the feature for the entire volume 
using the DCL command SET VOLUME/ERASE_ON_DELETE. When 
files are deleted, this command overwrites all files on the volume with the 
erasure pattern of zeros. 


To completely erase the volume and enable erase-on-delete for the volume 
at volume initialization, use the DCL command INITIALIZE/ERASE. 


By default, VMS writes a default data security erase (DSE) pattern 

of zeros, applied during a single WRITE operation over the area, when 
erase-on-delete is enabled. If you feel that the default pattern of zeros 

or the single rather than multiple number of erasures does not suit your 
requirements, you can use the $ERAPAT (Get Security Erase Pattern) 
system service to write a customized erasure pattern to specified files. See 
the description of $ERAPAT in the VMS System Services Reference Manual 
for more information. 


Generally, for sites with high-level security requirements, a random 
pattern is preferable to a fixed pattern. The technology is already available 
that can detect and use faint residual magnetic impressions. Thus, if you 
conclude there is sufficient danger that a disk might be removed and read 
by some of this specialized analysis equipment, you might need to rewrite 
the erasure pattern several times. You can learn how to customize the 
data security erase pattern to fit your needs by studying the information 
provided in the file SYS$EXAMPLES:DOD_ERAPAT.MAR. 


Employ erasing patterns only on disks where the security needs are the 
greatest. Erasures are time-consuming and affect system performance. 


5.7.2. Prevention Through Highwater Marking 


Section 4.7 introduces the concept of highwater marking. Highwater 
marking refers to a technique that tracks the furthest extent to which 
each file has been written and prohibits user attempts at reading data 
beyond that point. 


The VMS operating system implements true highwater marking for all 
sequential, exclusively-accessed files, such as the set of files output from 
various text editors, compilers, and linkers; that is, most files a process 
writes. The highwater mark is updated in the file header whenever the 
logical end-of-file mark is updated (usually when the file is closed). 
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For indexed as well as sequential, shared files, the VMS operating system 
uses the principle of erase-on-allocate to achieve a result similiar to 
true highwater marking. When a file is about to be created or extended, 
VMS determines how much disk space (the extent of the file) is required 
and applies the security erasure pattern of zeros to the areas (extents) it 
allocates for writing. The file is then written into the area just erased for 
it. Thus, if any user gains access to the file (including its full extent) and 
attempts to read the area beyond where the file has been written, only the 
data security erase pattern is readable. 


By default, VMS turns on highwater marking for all volumes. Highwater 
marking is a deterrent to disk scavenging attempts. However, it does 
require additional I/O, which affects system performance. 


You can turn off highwater marking on a volume-by-volume basis 
by specifying the DCL command SET VOLUME/NOHIGHWATER_ 
MARKING. 


5.7.3 Summary of Prevention Techniques 


Security administrators can apply the following controls to discourage disk 
scavengers: 


e Provide tight physical security, particularly on those disks with the 
most valuable information 


¢ Provide tight volume protection through UIC-based protection 


e Encourage the use of the /ERASE qualifier when key files are purged 
or deleted through user participation or volume enforcement 


¢ Permit default highwater marking on your most valuable disks 


5.8 Restricting the Environment—Limited-Access Accounts 


You should use limited-access accounts to create a restricted environment 
for the following situations: 


e Permitting unskilled or semi-skilled users to perform routine computer 
tasks 


e Running batch operations during unsupervised periods 


e Running applications programs with information that you want to 
keep private 


The VMS operating system provides two kinds of limited-access accounts: 
captive and restricted. These accounts, also called turnkey accounts, 
restrict the user’s access to the system, usually through a specialized login 
command procedure. 


The following sections describes captive and restriced accounts and provide 
examples of their use. Guest accounts and proxy login accounts, two other 
types of accounts typically set up as limited access accounts, are also 
described. 
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5.8.1. Creating a Captive Account 


A captive account limits the activities of the user and denies the user 
access to the DCL command level. You can set up the account to limit 
the user to running a specific program or command procedure. Define a 
captive account with AUTHORIZE by including the following qualifier 
when creating the account: 


/FLAGS=(CAPTIVE) 


This flag ensures that the account is noted as captive and provides the 
following features: 


¢ Disables direct access to the DCL command level. If unhandled errors 
or attempted interrupts (the use of CTRL/Y, for example) occur, a 
system error message is generated and the session is logged out. 


e Disables the use of the INQUIRE command. 

¢ Prevents the user from specifying any of the following login qualifiers: 
— /CLI—specifies the name of an alternate command line interpreter 
— /COMMAND—overrides the default login command procedure 


— /NOCOMMAND—disables execution of the default login command 
procedure 


— /DISK—requests an alternate default disk 
— /TABLES—specifies the name of an alternate CLI table 


¢ Ensures that the system login command procedure (SYLOGIN.COM) 
and the process login command procedure (specified by the /LGICMD 
qualifier in the UAF), as well as any command procedures they call, 
are executed. 


¢ Sets the initial state of the DISCTLY flag to ON to disable the use of 
CTRLY. 


e Prevents the use of the SPAWN command from MAIL and the use of 
the SPAWN built-in procedure from VAXTPU. 


You may want to disable the welcome announcement and electronic mail 
for the captive account. This is done by setting the DISWELCOME, 
DISMAIL, and DISNEWMAIL login flags. 


Decide whether users should be able to change the password for the 
captive account. There are two password options appropriate with captive 


accounts: 
¢ Require no password by specifying the AUTHORIZE qualifier 
/NOPASSWORD. 


¢ Lock the password with the /FLAGS=LOCKPWD qualifier so that only 
the security administrator can change it. 


Locked passwords are generally preferable to open captive accounts (those 
with no password). If you assign a locked password, give that password to 
all users of the captive account. 


System Security Implementation 
5.8 Restricting the Environment—Limited-Access Accounts 


Your application may require you to impose additional AUTHORIZE 
qualifiers on the account, such as /NODIALUP, to restrict modes of 
operation. Consider imposing restrictions for the periods of the day and 
days of the week when the process can run. 


You can define a special set of DCL tables using the /CLITABLES qualifier, 
or you can emulate DCL through the use of a DCL command procedure. 
It is more efficient to define DCL tables than to resort to a DCL command 
procedure to emulate DCL. See the description of the VMS Command 
Definition Utility in the VMS Command Definition Utility Manual for help 
in defining the DCL tables. 


You should rarely need to grant any privilege other than TMPMBX to a 
captive account. 


Limit the disk quota for the captive account to the amount needed. 


Login Command Procedure Considerations 


The primary feature of the captive account is its login command procedure. 
To override the default login command procedure (LOGIN.COM in the 
user’s default directory), identify the captive account login command 
procedure with the AUTHORIZE qualifier /LGICMD. Use the following 
guidelines to make certain that the login command procedure is 
tamperproof: 


e Ifthe captive account user is allowed to create or perform other 
operations on files, make certain that WRITE access to the login 
command procedure and its directory is denied. (EXECUTE access is 
required.) 


e Ensure that the account is not a member of the SYSTEM group (has 
a group value less than or equal to 10 octal, unless modified by the 
SYSGEN parameter MAXSYSGROUP). 


¢ Give the captive account a unique UIC group. Use the following form 
of the AUTHORIZE command SHOW to verify this: 


SHOW [groupuic,*]) 


By keeping the account in a separate group, you can ensure that the 
captive users can only access WORLD-accessible files and files owned 
by the captive account. 


The DCL command INQUIRE is disabled for accounts with the CAPTIVE 
flag set. You must use the READ/PROMPT command instead to prompt 

a user for input during a captive account session. Use of the INQUIRE 
command in a captive command procedure produces an error that, if 
unhandled by a previous ON declaration, results in deletion of the process. 


If the function of the command procedure requires text preparation, 
you may want to give users access to an editor. When designing this 
environment, remember that most editors are capable of reading and 
writing files (within the access rights of the account). 


Note: Do not permit the captive account command procedure to use the 


TECO editor because it can break out of any captive command 
procedure. 
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Example 5-4 shows a command procedure that provides a completely 
captive environment, restricting the user to a limited set of commands. 
Note that the security administrator would use the AUTHORIZE qualifier 
/NOINTERACTIVE when establishing this account. 


Example 5-4 A Sample Captive Command Procedure 





deassign sys$input 

previous sysinput == f$logical ("SYSSINPUT") 
on error then goto next_command 

on control_y then goto next_command 

set control=(y,t) 


next_command: 
on error then goto next_command 
on control_y then goto next_command 


if previous_sysinput .nes. fS$logical("SYSSINPUT") then deassign sys$input 
read/end=next_command/prompt="$ " sys$command command 

command == fSedit (command, "UPCASE, TRIM, COMPRESS") 

if £$length(command) .eq. 0 then goto next_command 


delete = "delete" 

delete/symbol/local/all 

if f$locate("@",command) .ne. f$length(command) then goto illegal_command 
if f$locate("=",command) .ne. f$length(command) then goto illegal_command 
if f$locate("F$",command) .ne. f$length(command) then goto illegal_command 
verb = fSelement(0," ", command) 


if verb .eqs. "LOGOUT" then goto do logout 
if verb .eqs. "HELP" then goto do_help 


write sysSoutput "%SCAPTIVE-W-IVVERB, unrecognized command \",verb,"\" 
goto next_command 
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$illegal_command: 

$ write sysSoutput "SCAPTIVE-W-ILLEGAL, bad characters in command line" 
$ goto next_command 

$ 

$do_logout: 

$ logout 

$ goto next_command 

$ 

$do_help: 

$ define sysS$input sys$command 
$ help 

$ goto next_command 





Creating a Restricted Account 


Certain limited-access accounts require a less restrictive environment 
than captive accounts. Accounts under which network objects run, for 
example, require temporary access to DCL. Such accounts must be set up 
as restricted accounts, not captive accounts. (See Section 8.5.3 for details 
about network object accounts.) 
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Define a restricted account with the Authorize Utility (AUTHORIZE) by 
including the following qualifier when creating the account: 


/FLAGS=(RESTRICTED) 


This flag ensures that the account is noted as restricted. A restricted 
account provides the same features as those listed for a captive account in 
Section 5.8.1 with the following differences: 


e Restricted accounts allow the user access to the DCL command level 
following the execution of the system and process login command 
procedures. 


e Use of the INQUIRE command in the system and process login 
command procedures is not disabled. (Use the READ/PROMPT 
command, as described later in this section, to prompt restricted 
account users for input.) 


With the following two types of restricted applications, it is appropriate to 
allow the user to enter the CTRL/Y command subsequent to the startup of 
the command procedure: 


¢ You may want to provide users with a CTRL/Y feature at points during 
the execution of the restricted login command procedure. Include ON 
CONTROL_Y commands in the procedure where you want to test for 
CTRL/Y, as shown in Example 5-4. 


¢ ‘You may have a restricted command procedure that ultimately turns ( 
control over to the user. For example, consider a SYLOGIN.COM 
command procedure that performs additional security validation; its 
execution should be guaranteed to ensure its effectiveness. However, 
once SYLOGIN.COM has done its job, control can be turned over to 
the user. To do this, mark the account as restricted and enter the DCL 
command SET CONTROL=Y when you are ready to release control to 
the user, as shown in Example 5-5. 


Do not allow the DCL command INQUIRE to appear in any command / 
procedures. The INQUIRE command performs an evaluation while \ 
receiving input, which could create an opening to break the restricted 

account. Instead, use the DCL command READ/PROMPT. 


For example, to request the user to enter the date, enter the following 
command: 


READ/PROMPT="Enter date: " SYS$COMMAND DATE 


For similar reasons, avoid any use of the construction ’x, where x contains 
a string entered by the user. Never permit a restricted command 
procedure to attempt an evaluation of a symbol that the user enters. 

Use of lexical functions could break the command procedure. 


Set the AUTHORIZE qualifier /PRCLM (subprocess limit) to 0 to prevent 

the user from spawning out of the restricted account. (Verify that the 

SYSGEN parameter PQL_MPRCLM—the minimum subprocess limit—is 

set to 0.) ( 
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The sample restricted command file in Example 5-5 can be used on 
privileged accounts. To allow only interactive use of the account from 
a local terminal, include the AUTHORIZE qualifiers /NODIALUP, 
/NOREMOTE, /NOBATCH, and /NONETWORK when establishing the 
account. 


Example 5-5 Sample Restricted Procedure for Privileged Accounts 


§ 
$ 
$ 


wn 


-nes. "INTERACTIVE" then S$logout 
term = £$logical ("SYSSCOMMAND") 

if f$locate("_T", term) .eq. 0 then $goto allow 
if £$locate("_OP",term) .ne. 0 then S$logout 
Sallow: 

$ set control=(y,t) 


Use of the DISIMAGE Flag in Limited-Access Accounts 


The AUTHORIZE flag DISIMAGE prevents users from using the MCR 
or RUN commands to execute system or user-written images or from 
executing images defined as foreign commands. 


Because the DISIMAGE flag is enforced by the DCL command language 
interpreter (CLD, you must ensure that the account for which the 
DISIMAGE flag is set has access to the DCL CLI only. Use the DISIMAGE 
flag in conjunction with the AUTHORIZE flag DEFCLI or within a 
restricted account. (Setting the RESTRICTED flag for an account 
implicitly sets the DEFCLI flag.) 


Summary of Captive and Restricted Accounts 


Use the following guidelines to help you determine whether you should set 
up limited-access accounts as captive or restricted accounts: 


e Set up a captive account to limit users to running under the complete 
control of the captive login command procedure. No access to the DCL 
command level is allowed. 


e¢ Set up accounts that grant access to specific network objects (such as 
MAIL) as restricted accounts. 


e Ensure that existing accounts created as part of a layered product 
installation (such as the NOTES$SERVER account created during the 
installation of VAX NOTES) are set up as restricted 4 ccounts. 
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Guest Accounts 
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Guest accounts are forms of captive or restricted accounts that allow 
multiple remote users access to resources on your system through a 
common account. For example, users across the network may need access 
to your system to report problems or read corporate memos. 


Digital does not recommend the practice of setting up guest accounts. 
Guest accounts, however unprivileged, offer malicious users a chance 
to compromise your system security. Most needs for a guest account 

can be handled by special proxy login accounts, which should also be 
limited-access accounts. 


If you still need a guest account, take the following steps to make the 
account secure: 


¢ Use an obscure password for the guest account. Change the password 
frequently. Never use easily guessed account name and password 
combinations such as GUEST/GUEST or USER/USER. 


¢ Maintain a list of people allowed to use the account. (Changing the 
password regularly will help you keep this list current.) 


e¢ Set up the guest account in a separate UIC group. Make sure that the 
account is not a member of the SYSTEM group. . 


e Place the default login command procedure in the directory 
SYS$MANAGER using the AUTHORIZE command MODIFY, as 
follows: 


MODIFY guest-accoun/LGICMD=SYS$MANAGER ‘Filename.COM 


¢ Make the guest account restricted or captive by setting the 
AUTHORIZE qualifiers /FLAGS=RESTRICTED or /FLAGS=CAPTIVE, 
respectively. 


¢ Ifthe guest account is set up as a restricted account, limit the 
number of subprocesses that the account can create to 0 using 
the AUTHORIZE qualifier /PRCLM=0. (Ensure that the SYSGEN 
parameter PQL_MPRCLM is also set to 0.) 


e Assign the guest account only TMPMBX privilege. 


¢ To handle error conditions, include the following commands in the 
default login command procedure: 


SET ON 
SET NOCONTROLY 
ON ERROR THEN LOGOUT/BRIEF 


e If LOGOUT is defined as a global symbol and points to a command 
procedure (enter the DCL command SHOW SYMBOL LOGOUT to 
confirm this), include the following DCL command in the default login 
command procedure for the account: 


DELETE/SYMBOL LOGOUT/GLOBAL 


This will eliminate the possibility that the user could break the 
restricted account at logout time by typing CTRL/Y. 
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To prevent outsiders from misusing your system resources through 
the submission of batch jobs under the guest account, include the 
AUTHORIZE qualifier /NOBATCH when you create the account. 


Limit the disk quota for the guest account UIC to the amount needed. 


Do not allow the DCL command INQUIRE to appear in any of the 
command procedures. 


Proxy Login Accounts 


Generally, proxy login accounts should be set up as restricted accounts. 

Proxy login accounts permit remote users to access a local account without 
specifying a password. Section 8.6.1.2 describes proxy login accounts. Note 
that many recommendations are the same as those for restricted accounts. 


Ongoing Tasks 





Maintaining a secure system requires continuous surveillance. The 
following ongoing tasks are important to the system manager: 


Use the MONITOR IO report to develop a familiarity with the normal 
amounts of I/O on your system at various times. Watch for abnormal 
changes. 


Keep informed of the images installed on your system. Use the VMS 
Install Utility (INSTALL) to look for unexpected additions. 


Use the AUTHORIZE command SHOW on a regular basis to check for 
unauthorized user names. 


Use the AUTHORIZE command SHOW/PROXY regularly to quickly 
recognize all proxy access that you have authorized. Watch for 
unexpected additions. Remove any remote users who no longer require 
access. Institute regular communications with system managers at 
remote nodes. 


Apply the VMS Accounting Utility on a regular basis to give you a 
basis of normal amounts of processing time. Watch for unexplained 
changes. 


Regularly check the accounting report produced by ACCOUNTING for 
known user names, unknown user names, and appropriate hours of 
system use. 


Develop sufficient familiarity with your system’s workload so that you 
notice normal (as well as abnormal) processing activity occurring at 
unusual hours. 


Monitor device allocations routinely with the DCL command SHOW 
DEVICE so that you will immediately notice any that are unexpected. 


Become familiar with the recurring types of batch jobs that run on the 
batch queues and what times they are most likely to run. 


Monitor the protection and ownership of critical files with the 
DIRECTORY/SECURITY command. Watch for unexplained changes in 
each. 
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Maintain familiarity with the rights database. Keep current listings so 
that you can recognize identifiers that have been added or new holders 
of the current identifiers. 


Remove identifiers that are not in use. Keep the rights database 
current. 


Regularly review the templates that you use to set up UAF records. 
Make any changes necessary. 


Use the security auditing features described in Chapter 6. 


Apply the VMS Audit Analysis Utility regularly to detect abnormal 
auditing activity. 


Try to break into your user accounts with some obvious password 
choices. 


When you allow new users to change their initial passwords, check 
back to see if you can log in with the password you originally assigned. 
Where necessary, follow up with the user to find out why the change 
did not occur as requested. 


Try searching unprotected user files for passwords embedded in 
network access control strings. The password will precede the 
3-character terminator ("::). Also search for the noun “password”, and 
see if any passwords are revealed nearby. 


aN 


Check that your users are logging out properly. Make physical checks 
at the end of normal business hours. 


Check that your users have appropriate default protections in place. 


Keep informed about your inventory of magnetic tapes, disks, 
and program listings. Routinely check that inventory for possible 
indications that physical security has degraded. 


Keep your office and all important listings locked up. 


6 Securiiy Auditing 


Security auditing is the act of recording security-relevant events as they 
occur on the system. Audit analysis is the periodic review of the security 
audit records. By auditing system events and performing regular audit 
analysis on this information, you can more easily recognize attempts to 
compromise the security of your system. 


This chapter describes the security auditing and audit analysis features 
available under the VMS operating system. It also explains how you can 
modify existing security auditing features to match the level of security 
required at your site. 


Resources consumed by the VMS security auditing facility vary with the 
number and type of system events being recorded. This chapter explains 
how the security auditing facility monitors resource consumption on the 
system and describes what happens if available resources are insufficient. 


6.1 Overview of VMS Security Auditing 


Note: 


The primary function of security auditing is to capture information about 
users whose actions might have significance for system security. Under 
the VMS operating system, the types of security-related events that occur 
on the system can be divided into a number of categories, called event 
classes. (See Section 6.3 for a complete list of event classes.) 


By default, security auditing is enabled for the following situations (or 
classes of security events) when you install or upgrade your system: 


e ©All uses of the SET AUDIT command. 


e All changes to the System User Authorization File (SYSUAF), 
Network Proxy Authorization File (NETPROXY), and rights database 
(RIGHTSLIST). 


e All break-in attempts 


You use the DCL command SET AUDIT to enable or disable security 
auditing, to change the event classes currently being audited, or to modify 
any auditing features currently enabled on the system. See the VMS DCL 
Dictionary for a complete description of the SET AUDIT command. 


Security events on the system result in two forms of output: alarms and 
audits. Alarms are one-time notifications of security events that are sent 
to all terminals enabled as security operators. Audits are the recorded 
history of security events that can be retrieved and analyzed at a future 
date. 


All security events are propagated as both alarm messages at 
security operator terminals and as system audits written to the 
system security audit log file. Digital intends to remove this 
restriction in a future version of the VMS operating system and 
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allow you to control whether classes of security events generate 
alarms, audits, or both. 


All security audit messages are recorded in the system security audit log 
file. Section 6.4 describes how you can use the VMS Audit Analysis Utility 
to review the security audit messages written to the log file. 


Figure 6-1 illustrates the relationship among the VMS security auditing 
subsystem components and shows the flow of security events as they are 


formatted into alarm messages and entries in the system security audit 
log file. 


Figure 6-1 Security Auditing on a VMS System 
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The callouts in Figure 6-1 label the path that security events take through 
the VMS operating system: 


@ A security event is generated (based on the event classes enabled 
on the system) and written to the operator communication manager 
(OPCOM) mailbox (MBA2) as a binary message. 


@ OPCOM reads and reformats the message and writes the message to 
the audit server process (AUDIT_SERVER) mailbox (MBA3). 


@ AUDIT_SERVER reads the message. 
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AUDIT_SERVER writes a copy of the binary message to the listener 


device, if enabled. 
@ AUDIT_SERVER writes a copy of the binary message to the security 


archive file, if enabled. The security archive file may be located on a 
remote system. 


© AUDIT_SERVER writes a copy of the binary audit message to the 
system security audit log file. This is called a system audit. 


@ AUDIT_SERVER formats the binary message into ASCII text and 
sends the alarm message to OPCOM (using the $SNDOPR system 
service). 


© Using the $BRKTHRU system service, OPCOM displays the message 
at all terminals enabled as security operators. This is called a system 
alarm. 


© In addition to sending alarm messages to OPCOM (as shown in callout 
@), AUDIT_SERVER also sends error and informational messages 
to OPCOM. OPCOM copies these messages to the operator log file 
(OPERATOR.LOG). 


The components of the VMS security auditing subsystem are described in 
more detail in the following section. 





6.2 Security Auditing Components 


Table 6—1 lists the components of the VMS security auditing subsystem 
illustrated in Figure 6-1. 


Table 6-1 Security Auditing Components 


Component Description 
Audit server process Performs security auditing on the system: 
(AUDIT_SERVER) controls logging of security events to a 


clusterwide security audit log file; monitors 
resources (virtual memory and disk space) 
required for security auditing; prevents the loss 
of security information when resources are 


depleted. 

Operator communication Passes audit messages to the audit server 

manager (OPCOM) process; sends security alarm messages to all 
security operator terminals. 

Security audit log file Maintains a record of security audit messages 
generated. 

Security archive file Serves as a site for long-term storage of audit 
messages. 

Listener device User-defined mailbox created to receive real- 


time security messages. 


The following sections describe the parts of the security auditing 
subsystem in greater detail. 
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Audit Server Process 


6.2.1.1 


The audit server process (AUDIT_SERVER) is a detached process created 
during the system bootstrap. AUDIT_SERVER controls security auditing 
on the system by performing the following functions: 


¢ Creates a binary, clusterwide, security audit log file. 
e Enables security auditing for a default set of security events. 


¢ Maintains a private database (see Section 6.2.1.1) containing the 
current security auditing characteristics. The information stored 
in the database is updated dynamically whenever you use the SET 
AUDIT command to modify security auditing features on the system. 


¢ Monitors system resources to prevent the loss of security event 
messages. (Resource monitoring features are described in Section 6.5.) 


Audit Server Database 

The audit server process performs security auditing on the system by 
using a collection of information known as the audit server database. 
This database is updated whenever security auditing characteristics are 
modified and restored each time the system is rebooted. . 


The audit server database AUDIT_SERVER.DAT is created in the system 
manager directory when you first install or upgrade your VMS system. 
AUDIT_SERVER.DAT initially contains the following security auditing 
information: — 


e The name and location of the system security audit log file. By default, 
the file is named SECURITY_AUDIT.AUDIT$JOURNAL and is located 
in the system manager directory SYS$COMMON:[SYSMGR]. See 
Section 6.2.3.2 for information about redirecting the security audit log 
file. 


e The default set of security audit event classes to be logged to the 
system security audit log file. These are: AUTHORIZATION, AUDIT, 
and BREAKIN. 


¢ Information used by the audit server process to monitor the 
consumption of resources on the system. 


¢ The security alarm failure mode, which is initially set to WAIT, 
indicating that processes are put into MWAIT state until system 
resources are available. 


If you enable security archiving (see Section 6.2.4), the audit server 
database also contains the name and location of the security archive file 
and the classes of information being logged to the file. 


Use the SHOW AUDIT/ALL command to display the current auditing 
characteristics. 


Moving the Audit Server Database 


See Section 6.2.3.2 for information about moving the audit server database 
from its default location in the SYSS$MANAGER directory. 
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All VAX systems running the VMS operating system start the operator 
communication manager (OPCOM) and the audit server process (AUDIT_ 
SERVER) by default. If the physical memory or disk storage space on your 
system is especially limited and logging of security-related events is not 
important, you might consider removing these processes from the system 
startup procedure with the System Management Utility (SYSMAN), as 
shown in the following example: 


$ SET PROCESS/PRIVILEGES= (OPER, BYPASS) 

$ RUN SYSSSYSTEM: SYSMAN 

SYSMAN> STARTUP SET DATABASE STARTUPS$STARTUP_VMS 

SYSMAN> STARTUP DISABLE FILE VMSSCONFIG-050_OPCOM.COM/NODE=* 
SYSMAN> STARTUP DISABLE FILE VMS$CONFIG-050_ AUDIT _SERVER.COM/NODE=* 
SYSMAN> EXIT 

$ SET PROCESS/PRIVILEGES= (NOOPER, NOBYPASS) 


To delete the audit server process and shut down security auditing on the 
system, enter the following command: 


$ SET AUDIT/SERVER=EXIT 


Repeat the preceding command on each node in the cluster. 


Restarting Security Auditing 


You can restart OPCOM and security auditing on the system by executing 
the following DCL commands: 


$ @SYSSSYSTEM: STARTUP OPCOM 
$ SET AUDIT/SERVER=START 


To start the OPCOM and AUDIT_SERVER processes for all subsequent 
system boots, edit the system startup procedure using the following 
SYSMAN commands: 


$ SET PROCESS/PRIVILEGES= (OPER, BYPASS) 

$ RUN SYSSSYSTEM: SYSMAN 

SYSMAN> STARTUP SET DATABASE STARTUPSSTARTUP_VMS 

SYSMAN> STARTUP ENABLE FILE VMSSCONFIG-050 OPCOM.COM/NODE=* 
SYSMAN> STARTUP ENABLE FILE VMSSCONFIG-050 AUDIT_SERVER.COM/NODE=* 
SYSMAN> EXIT 


$ SET PROCESS/PRIVILEGES= (NOOPER, NOBYPASS) 
See the VMS SYSMAN Utility Manual for more information about using 


SYSMAN. 
6.2.1.3 Changing the Audit Server Flush Rates 


The audit server process does not write security event messages directly 
to the security audit log file and security archive file (if enabled). Instead, 
these messages are stored temporarily in VMS RMS buffers (software 
structures in memory). Then, VMS RMS writes these messages to the 
appropriate device. 


To ensure that audit messages are transferred from the RMS buffers to 
their respective log files in a timely manner, the audit server periodically 
flushes any buffered audit messages to the security audit log file and 
security archive file. 
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By default, AUDIT_SERVER flushes auditing messages from the RMS 
buffers every five minutes and archive messages every minute. Except for 
some high-security environments and instances where extreme numbers 
of audit messages are being generated on the system, this default should 
be sufficient. However, you can use the following SET AUDIT command to 
force all audit messages from the RMS buffers to their respective log files: 


$ SET AUDIT/SERVER=FLUSH 


You can also use the SET AUDIT command to modify the audit server 
flush rate. At high security sites, it may be desirable to flush audit and 
archive messages from the RMS buffers at higher-than-normal rates. 

For example, the following commands instruct AUDIT_SERVER to fiush 
security audit messages every two minutes and archive messages every 30 
seconds: 


$ SET AUDIT/INTERVAL=JOURNAL_FLUSH=00: 02 
$ SET AUDIT/INTERVAL=ARCHIVE_FLUSH=00: 00:30 


6.2.2 Operator Communication Manager 


6-6 


Note: 


As shown in Figure 6-1, the operator communication manager (OPCOM) 
works with the security auditing subsystem in two ways: OPCOM 
forwards event messages to the audit server process, and broadcasts 
security alarms to security operator terminals. 


When a security event occurs, OPCOM receives the binary event message 
and passes it to the audit server process. 


After writing each audit message to the security audit log file, AUDIT_ 
SERVER formats the binary message into ASCII text and sends the 
message to OPCOM. OPCOM broadcasts the message as a security alarm 
to all terminals set up as security operator terminals. 


The audit server process also sends informational and error messages to 
OPCOM. OPCOM broadcasts these messages to operator terminals and 
writes the messages to the operator log file. 


OPCOM stores the ASCII representation of all messages sent to the 
SECURITY operator class in the operator log file. Because the same 
messages are stored in binary format in the system security audit log 
file, you can conserve disk space by disabling the logging of SECURITY 
operator class messages to the operator log file with the following 
command: 


$ REPLY/LOG/DISABLE=SECURITY 


Because the audit server process directs critical messages— 
such as warning or resource monitoring messages—to both the 
CENTRAL and SECURITY class operators, you will not lose 
any critical auditing information by disabling the logging of 
SECURITY class messages. 


) 
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0.2.. System Security Audit Log File 


6.2.3.1 


The audit server process writes all security audit messages to the latest 
version of a file named SECURITY_AUDIT.AUDIT$JOURNAL in the 
SYS$COMMON:[SYSMGR] directory. This file is called the system 
security audit log file. 


The security audit log file is a clusterwide file; its binary format conserves 
disk space required by the security auditing software. An additional 
feature of the security audit log file is its public format, which allows 
third-party analysis tools to be developed. (The VMS Audit Analysis 
Utility Manual describes the format of the messages written to the security 
audit log file.) 


The usefulness of the security audit log file depends upon the procedures 
you adopt to review the file on a regular basis. For example, you might 
implement the following as part of your site audit review policy: 


1 Create a new version of the security audit log file each morning (see 
Section 6.2.3.1). 


2 Review the previous version of the log file for suspicious system 
activity (see Section 6.4). Depending on the number of security events 
that you are auditing on your system, it might be impractical to review 
every audit record written to the audit log file. In that case, you might 
want to select a specific set of records from the log file (for example, 
all AUTHORIZATION and BREAKIN records, or all events created 
outside normal business hours). 


3 If, during your review, you find any security events that appear 
suspicious or out of place (login attempts outside normal business 
hours, for example), perform a more detailed inspection of the security 
audit log file, as described in the VMS Audit Analysis Utility Manual. 
Otherwise, delete it. (See Section 6.2.4 for information about creating 
a security archive file for permanent storage of security auditing 
records.) 


Use the VMS Audit Analysis Utility to selectively report the contents of 
the security audit log file, as described in Section 6.4. 


Creating a New Version of the Security Audit Log File 
Use the following SET AUDIT command to create a new version of the 
clusterwide security audit log file: 


$ SET AUDIT/SERVER=NEW_LOG 


A new version of the audit log file is opened by the audit server process 
on each node in the cluster. To prevent the loss of audit messages, the 
previous version of the audit log file is not closed until all audit messages 
stored in memory are written to the file. 


In some cases, the nodes in a cluster may not share the same system 
security audit log file. In a multiple-environment cluster, you can specify 
the following SET AUDIT command to create a new version of the system 
security audit log file on the local node only: 


$ SET AUDIT/ SERVER=CREATE SYSTEM _LOG 
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6.2.3.2 


Note: 


System security audit log files on other nodes in the cluster are unaffected. 


Relocating the Security Audit Log File 

Each time the system is rebooted, the command procedure 
SYSECURITY.COM in the system manager directory is executed before 
the audit server process is started. You can use this command procedure 
to redirect the security audit log file and the audit server database from 
their default locations in the SYS$COMMON:[SYSMGR] directory. 


To relocate the system security audit log file or the audit server database 
to a disk other than the system disk, include the following lines in the 
procedure to mount the disk before the audit server process is started: 


$ if .not. f$getdvi ("$254SDUA118","mnt") - 
then mount/system $254$DUA118 audit audit$ /norebuild 


Replace $254$DUA118 with the appropriate disk name. 


To redirect the audit server database to the disk, you should also add a 
line to SYSECURITY.COM to define the system logical name AUDIT_ 
SERVER. For example, the following lines in SYSECURITY.COM mount 
the disk $254$DUA118 and redirect the audit server database to the 
alternate volume: 


$ if .not. f$getdvi("$254SDUA118","mnt") - 
then mount/system $254SDUA118 audit audit$ /norebuild 
$ define/system/exec audit_server audit$: [audit] audit_server.dat 


Finally, after the system reboots, redirect the security audit log file to the ( 
alternate volume mounted in SYSECURITY.COM, as follows: 


$ SET AUDIT/JOURNAL=SECURITY - 
_$ /DESTINATION=AUDITS$S: [AUDIT] SECURITY_AUDIT.LOG 
$ SET AUDIT/SERVER=NEW_LOG 


In the preceding example, the first command updates the audit server 
database with the new location of the security audit log file, and the 

second command instructs the audit server process on each node in the 
cluster to open the file. ‘i 


If you use a logical name in the specification of the system 
security audit log file, you must define the logical name in 
SYSECURITY.COM. 


For a multiple-environment cluster, specify the following SET AUDIT 
commands to redirect the system security audit log file on the local node 
only: 


$ SET AUDIT/JOURNAL=SECURITY/DESTINATION=file-name 
$ SET AUDIT/SERVER=REDIRECT_SYSTEM_LOG 


System security audit log files on other nodes in the cluster are unaffected. 
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6.2.4 Security Archive File 


An archive is a place for storing records. The VMS operating system 

allows you to create a security archive file to store long-term security 
event messages. The security archive file contains auditing records in 
binary format. 


As illustrated in Figure 6-1, the audit server process writes a copy of each 
auditing message to the security archive file (if enabled) before writing the 
message to the security audit log file. 


Specify the following form of the SET AUDIT command to enable security 
archiving on the system: 


$ SET AUDIT/ARCHIVE/DESTINATION=file-spec 


The file specified by the file-spec keyword is created, and all event 
messages are written to the file. 


Note: If you use a logical name in the specification of the 
security archive file, you must define the logical name in 


SYSECURITY.COM. 
6.2.4.1 Enabling Remote Security Archiving 


The location of the security archive file is not limited to the cluster; you 
can set up the security archive file on a remote node through the use of a 
network proxy account. 


Use the following procedure to write system audit messages to a remote 
security archive file: 


1 Log in to the remote node, and create a network proxy account for the 
audit server process. See Section 8.6 for information about setting up 
proxy accounts. The proxy account should be an unprivileged account 
set up with network access only; the account must have access to the 
device and directory containing the security archive file. 


2 Add proxy access on the remote node. This allows the audit server 
process, which has a user name of AUDIT$SERVER, access to the 
proxy account. For example, the following commands grant the audit 
server process on node SMLNOD proxy access to the ARCHIVE 
account on node BIGNOD: 


$ SET DEFAULT SYSSSYSTEM 

$ RUN AUTHORIZE 

UAF> ADD/PROXY SMLNOD: :AUDIT$SERVER ARCHIVE/DEFAULT 
UAF> EXIT 


3 Log out from the remote node. On the local node, specify the following 
SET AUDIT command to initiate security archiving to the remote file: 


$ SET AUDIT/ARCHIVE=ALL/DESTINATION=BIGNOD: :device: [dir] file.typ 


You must supply a complete directory specification. If you include any 
logical names, they must be able to be translated by the local audit server 
process. 


Note: A remote security archive file is nonshareable; only one node can 
direct auditing messages to a security archive file on another node. 
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6.2.4.2 


Listener Device 


Analyzing the Security Archive File 

Audit analysis of the security archive file is identical, in most respects, to 
analysis of the security audit log file. The only notable difference is the 
frequency with which you perform audit analysis on the two files. 


Typically, you generate and review audit reports from the system security 
audit log file on a daily basis, while you might only generate audit reports 
from the security archive file when you discover a security threat on the 
system. By analyzing the security archive file, you can view the audit trail 
left by a user over a specified period of time. 


Note that you can analyze a remote security archive file at any time, even 
while the file is open. 


See Section 6.4 for complete information about retrieving selective 
information from the security archive file. 


As an additional feature of the security auditing subsystem, you can create 
a listener device that receives a copy of all system security audit messages 
as they occur. The listener device is a permanent or temporary mailbox 
that you create with the Create Mailbox and Assign Channel ($CREMBX) 
system service. The audit server process sends auditing messages to the 
listener mailbox, if it exists, before writing the message to the security 
audit log file and security archive file. (See Figure 6-1.) 


See the VMS System Services Reference Manual for a description of the 
Create Mailbox and Assign Channel ($CREMBX) system service. 


To enable the listener device to receive security audit messages, execute 
the following DCL command: 


$ SET AUDIT/LISTENER=device-name 


Replace the device-name keyword with either the logical name specified 
when you created the mailbox or the equivalence name of the mailbox, in 
the form of MBAn, where n represents the unit number of the mailbox. 
If you create the device as a temporary mailbox, you must use the Get 
Device and Volume Information ($GETDVI) system service to return the 
mailbox device name. 


Refer to the files AUDSRV_LISTENER.B32 (VAX BLISS program) 

and AUDSRV_LISTENER.MAR (VAX MACRO program) in the 
SYS$EXAMPLES directory for examples of a program that outputs audit 
event messages sent to the listener mailbox on a DECtalk device. 


Defining Security Events To Be Audited 
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As a VMS system manager or site security administrator, you must 
determine the level of security required at your site before you can 
understand what set of system security events you should audit. 


Note: 
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By defauit, security auditing is enabied for the foliowing ciasses of security 
events when you install your system or upgrade from a previous version of 
the VMS operating system: 

e All uses of the SET AUDIT command 


e All changes to the System User Authorization File (SYSUAF), 
Network Proxy Authorization File (NETPROXY), and rights database 
(RIGHTSLIST) 


e All break-in attempts 
If the security requirements at your site warrant it, you can enable 
security auditing for additional classes of security events. To add to 


the default list of security event classes to be audited, specify the DCL 
command SET AUDIT in the following format: 


SET AUDIT /ALARM /ENABLE=keyword....] 


Select the events to be audited by specifying one or more of the following 
keywords to the /ENABLE qualifier: 


e ACL—Event requested by an ALARM JOURNAL ACE on a file or 
global section ACL 


¢ ALL—AIll possible events 


e FILE_ACCESS—Selected types of access (privileged and nonprivileged) 
to files and global sections 


¢ INSTALL—Installation of images 

¢ LOGFAILURE—Failed login attempt 

¢ LOGIN—Successful login attempt 

¢ LOGOUT—Logout 

¢ MOUNT—Volume mounts and dismounts 

For example, specify the following SET AUDIT command to add ACL and 
LOGFAILURE to the classes of security events audited on the system: 

$ SET AUDIT/ALARM/ENABLE= (ACL, LOGFAILURE: ALL) 


Execute the SHOW AUDIT command to view the complete list of audited 
event classes. 


To disable security auditing for specific event classes, specify the 
/DISABLE qualifier to the SET AUDIT command in the following format: 


SET AUDIT /ALARM /DISABLE=keyword]....] 


The AUDIT class of events, which includes all uses of the SET AUDIT 
command, cannot be disabled. 


See the VMS DCL Dictionary for more information about the SET AUDIT 
command. 


Security auditing is automatically started by the system. You 
are not required to enable security auditing in your site-specific 
startup command procedure. 
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See Section 7.2.2 for suggestions about which events you should enable if 
you suspect your system is under attack. 


6.3.1. Enabling a Security Operator Terminal 


SEEESESESSS 
Messages 


Before you enable alarms for particular events, enable a security operator’s 
terminal. Choose a terminal that provides hardcopy output and is located 
in a secure location. The following DCL command enables the terminal 
from which the command is entered: 


$ REPLY/ENABLE=SECURITY 


Any number of terminals can be enabled as security operators. If you 
designate one terminal as the security operator’s terminal, add the 
following lines to the site-specific startup command procedure to send 
alarms to the terminal and disable them on the system console: 


$ DEFINE/USER SYSSCOMMAND OPAO: 
$ REPLY/DISABLE=SECURITY 

$ DEFINE/USER SYSSCOMMAND TTA3: 
$ REPLY/ENABLE=SECURITY 


After you enable a security operator terminal, the terminal receives alarm 
messages when the selected events occur. Security alarms appear as 
follows: 


$% OPCOM 25-JUN-1989 12:27:52.26 %%%%%3%3%%%3%3% 0 
from user AUDITSSERVER on LASSIE 


Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 16777 


Auditable event: 
Event time: 

PID: 

Username: 

Image name: 

Object name: 

Object type: 

User record modified: 
Fields modified: 
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System UAF record modification 

25-JUN-1989 12:27:52.25 © 

23C00155 

MENACE 

$11SDUA53: [SYSO.SYSCOMMON.] [SYSEXE] AUTHORIZE. EXE 
SYSSCOMMON: [SYSEXE] SYSUAF .DAT;2 

file 

GOWER 

PRIVILEGES 


The information included in the alarm message depends on the type 
of event; in all cases, the alarm message contains the following four 
elements: 


@ OPCOM heading, which includes the date and time the alarm was 
sent 


Type of alarm event 


Date and time the alarm event occurred 


The user who caused the event, as identified by the user name and 
process identification (PID) 


Other information contained in alarm messages is specific to the type of 
event that the alarm signaled. Appendix E includes examples of the alarm 
messages associated with particular alarm events. 
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6.4 Analyzing Security Auditing Information 


Collecting security audit messages in the system security audit log file is 
useless without developing and implementing a procedure to periodically 
review the log file for suspicious activity. You can use the VMS Audit 
Analysis Utility to examine the data in the security audit log file. 


Execute the following command to invoke the Audit Analysis Utility: 
$ ANALYZE/AUDIT file-name 


In place of the file-name parameter, substitute the name of the file from 
which audit analysis reports are to be generated. For example, the name 
of the system security audit log file is SYSSMANAGER:SECURITY_ 
AUDIT. (The default file type is AUDIT$JOURNAL.) 


You can extract security event messages from the system security audit log 
file and display them on a terminal (or output to a file) using combinations 
of ANALYZE/AUDIT qualifiers. The Audit Analysis Utility also features 
an interactive, screen-oriented command mode, which you can invoke by 
entering CTRL/C during the display. After you enter interactive command 
mode, you can specify a record by number for viewing, specify different 
selection and exclusion criteria for viewing audit records, obtain online 
help, and move forward or backward by any number of records through 
the audit log file. 


To extract all the security audit information from the current security 
audit log file, execute the following command: 


$ ANALYZE/AUDIT SYSSMANAGER: SECURITY AUDIT 


The following sections describe how you define the destination and format 

of the output from the Audit Anlysis Utility and some of the qualifiers you 
use to select specific information from the log file. Refer to the VMS Audit 
Analysis Utility Manual, however, for complete information about the VMS 
Audit Analysis Utility. 


6.4.1. Specifying the Audit Analysis Output Format 


Output from the security audit log file is displayed on SYS$OUTPUT. 
If you want to write the records to a file, include the file specification 
with the /OUTPUT qualifier. The following command writes all recorded 
security events to the file AUDIT_TODAY.DAT in the user’s current 
default directory: 


$ ANALYZE/AUDIT SYSSMANAGER:SECURITY_AUDIT - 
_$ /OUTPUT=AUDIT_TODAY.DAT 


By default, the Audit Analysis Utility displays reports from a security 
audit log file using a brief, 1-line format. You can specify a full 
format audit analysis report, which contains complete information 
for each auditing message, by including the /FULL qualifier with the 
ANALYZE/AUDIT command, as follows: 


$ ANALYZE/AUDIT/FULL SYS$MANAGER: SECURITY _AUDIT/SINCE=09:00 
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6.4.2. Displaying Selective Security Auditing Information 


The ANALYZE/AUDIT command accepts a number of qualifiers that define 
the format of the audit records extracted from the security audit log file 
and the type of information displayed. Using these qualifiers, you can 
select audit information generated in the following ways: 


e By specific users 
e¢ Within a particular time frame 


e By particular types of alarms 


For example, the following command extracts all security audit records 
generated by the user SARDONO after July 1, 1989: 


$ ANALYZE/AUDIT SYSSMANAGER:SECURITY_AUDIT - 
_§$ / SELECT=USERNAME=SARDONO/SINCE=1-JUL~1989 


Use the /EVENT_TYPE qualifier to select audit information that resulted 
from a particular type of event. The VMS operating system audits a 
number of events that are enabled by specifying keywords with the 
/ENABLE qualifier of the SET AUDIT command. Use the same keywords 
to select the alarm information from the security audit log file. 


For example, the following command extracts all security audit records 
generated by break-in attempts, any access to a file using the SYSPRV 
privilege, or any access to a file using the BYPASS privilege: 


$ ANALYZE/AUDIT SYSS$MANAGER: SECURITY _AUDIT - 
_§ /EVENT_TYPE= (BREAKIN, FILE _ACCESS=(SYSPRV, BYPASS) ) 


Refer to the VMS Audit Analysis Utility Manual for a complete description 
of all ANALYZE/AUDIT qualifiers. 


6.5 Monitoring Security Auditing Resources 


6-14 


An important function of the audit server process is to monitor system 
resources and alert you when resource limitations occur that threaten 
the orderly processing of security auditing messages. Possible security 
auditing resource problems include the following: 


e The rate of messages being written to the OPCOM mailbox exceeds its 
capacity. (See Section 6.5.1.) 


¢ There is insufficent disk space on the device that holds the system 
security audit log file. (See Section 6.5.2.) 


¢ There is insufficient virtual memory for the audit server process. (See 
Section 6.5.3.) 


¢ The logical link connection to a remote node (containing the security 
archive file) is broken. (See Section 6.5.4.) 


Figure 6-2 outlines the areas (A, B, and C) of potential resource problems 
in the security auditing subsystem. 
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Figure 6-2 Areas of Potential Security Auditing Resource Problems 
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The following sections describe the default actions the audit server process 
takes for each type of resource problem and the ways that you can modify 
the defaults to fit your security environment. 


6.5.1 Overflowing the OPCOM Mailbox 


When the system places excessive demands on the operator communication . 
manager (OPCOM), the OPCOM mailbox (MBA2) may overflow. The 
OPCOM mailbox is the software structure that accepts incoming system 
event messages. (See Area A in Figure 6-2.) The problem could be caused 
by too many security event messages or a surge in system events or 

error messages generated from other sources, such as the VAXcluster or 
DECnet-VAX facilities. 


By default, the system places processes attempting to write messages 

to OPCOM in the MWAIT state if the OPCOM mailbox is full. These 
processes remain in this state until the OPCOM mailbox is no longer 
full. You can override this behavior and direct the system to either ignore 
security messages that overflow the OPCOM mailbox, or force a system 
failure. 
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Note: 


Specify the following SET AUDIT command to cause the VMS operating 
system to ignore failed security event messages: 


$ SET AUDIT/ALARM/FAILURE_MODE=IGNORE 


All event messages that cannot be written to the OPCOM mailbox are 
ignored. The first failed message causes an error message to be written 


to the operator console. The system maintains a count of lost messages, 
which can be displayed with SHOW AUDIT. 


Specify the following SET AUDIT command to cause the VMS operating 
system to force a system failure if messages cannot be written to OPCOM: 


$ SET AUDIT/ALARM/FAILURE_MODE=CRASH 


For most sites, the default behavior (suspend processes in the MWAIT 
state until resources are available) is acceptable. 


/FAILURE_MODE qualifier settings are not currently stored in 
the audit server database and must be reset in your site-specific 
startup command procedure during each system boot. 


6.5.2 Running Out of Disk Space 
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The audit server process constantly monitors the remaining disk space 
available on the disk volume or volume set containing the security audit 
log file. (See Area B in Figure 6-2.) If the available disk space on the 
volume becomes too small, the audit server process broadcasts a message 
to all security operator terminals indicating the problem, along with the 
number of free disk blocks on the volume. These messages are repeated 
every minute until you free up adequate space on the volume, or until the 
severity of the disk space problem reaches a more critical level. 


There are three important thresholds related to the monitoring of disk 
space by the audit server: warning, action, and resume. When disk space 
is too low, the audit server process reaches the warning threshold. When 
the audit server process begins suspending noncritical system processes, it 
has reached the action threshold. The resume threshold indicates that you 
have created enough free space on the disk volume containing the system 
security audit log file to restart normal system activity. 


Figure 6-3 illustrates the sequence of resource thresholds reached as the 
disk volume holding the system security audit log file runs out of free 
blocks and subsequently gains back enough disk space to resume normal 
system activity. 


The callouts in Figure 6-3 label the chain of events that typically occur 
when the space on the disk volume containing the audit log files gets too 
small: 


@ The available free space on the disk volume containing the system 
audit log file drops below 1000 blocks, the default warning threshold. 
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Figure 6-3 Resource Monitoring Threshoids 
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A warning message is broadcast to all security operator terminals 
indicating the amount of space needed on the disk volume in order to 
bring the free disk space to the minimum level. An identical message 
is sent each minute until you free enough space on the disk volume, or 
until the action threshold is reached. 


@ The available free space on the disk volume drops below 250 blocks, 
the default action threshold. 


Most system processes are suspended to slow down the rate of security 
events being generated and avoid losing audit messages. Logins are 
disabled. You must log in to an account with OPER privilege and 
recover enough space on the disk volume to bring the remaining free 
blocks above the resume threshold. 


If you allow the system to remain at the action threshold too long, the 
audit server process may run out of process virtual memory and take 
additional action to preserve audit messages (see Section 6.5.3). 


© The free space on the disk volume rises above 750 blocks, the default 
resume threshold. 


The resume threshold indicates that enough space has been recovered 
on the disk volume to resume normal system activity. Processes are 
resumed and logins enabled; however, the audit server continues to 
issue warning messages every minute until you recover enough free 
space to increase the free block count above the warning threshold. 


@ The free space on the disk volume rises above 1000 blocks, the default 
warning threshold. Normal system activity is resumed. No more 
warning messages are sent. 
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6.5.2.1 


Note: 


Changing Disk Monitoring Resource Thresholds 

The audit server process normally performs disk resource monitoring 
based on the number of free blocks on the disk volume containing the 
audit log file. Optionally, you can modify the audit server to monitor disk 
resources in any of the following modes: 


SPACE Controls whether resource monitoring is based on the number 
of free blocks on the disk. This is the default method used for 
resource monitoring. 


COUNT Controls whether resource monitoring is based on the amount 
of free disk space required to store a fixed number of event 
messages. 

PERCENTAGE Controls whether resource monitoring is based on the percentage 


of the disk volume or volume set available. 


TIME Controls whether resource monitoring is based on the amount of 
free disk space needed to store events that occur over a fixed 
period of time (in seconds). 


Specify the following form of the SET AUDIT command to modify the way 
the audit server monitors the disk: 


SET AUDIT/JOURNAL=SECURITY/RESOURCE=MONITOR_MODE=mode 


For example, the following command tells the audit server to monitor disk 
resources based on the amount of time remaining before the disk runs out 
of space: 


$ SET AUDIT/JOURNAL=SECURITY/RESOURCE=MONITOR_MODE=TIME 


By default, the audit server process crosses the resource warning threshold 
when space for only 1000 seconds (about 15 minutes) of audit messages 
remains. 


Table 6—2 lists the default warning, action, and resume thresholds for each 
resource monitor mode. Normally, the defaults listed should be sufficient. 
Table 6-2 Default Resource Monitoring Thresholds 


Resource Monitoring Thresholds 


Monitor Mode WARNING ACTION RESUME 
SPACE (blocks) 1000 250 750 
PERCENTAGE (of volume) 1 0 1 
COUNT (number of messages) 5000 1250 3750 
TIME (seconds) 1000 250 750 


Whenever you switch monitor modes, the audit server process 
resets the threshold values to the defaults listed in Table 6-2. 


Specify the following form of the SET AUDIT command to change the 
values of any of the resource monitoring thresholds: 


SET AUDIT/JOURNAL=SECURITY/THRESHOLD=type=value ( 


6.5.2.2 


6.5.2.3 
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For example, the following command raises the audit server resume 
threshold to 2000 blocks: 


$ SET AUDIT/JOURNAL=SECURITY/THRESHOLD=RESUME=2000 
Note that the values you specify for each threshold depends on the mode 
of resource monitoring currently enabled on the system. 


Adding Processes to the Process Exclusion List 
If an action threshold is reached, the audit server process suspends all but 
the following system processes: 


¢ CACHE_SERVER 

¢ CLUSTER_SERVER 
e CONFIGURE 

¢ JOB_CONTROL 

¢ OPCOM 

e SWAPPER 

¢ VWS$DISPLAYMGR 
¢ VWS$EMULATORS 


These critical processes, called the process exclusion list, will never be 
suspended if resource monitoring reaches the action threshold. 


Specify the following form of the SET AUDIT command to add a process to 
the process exclusion list: 


SET AUDIT/EXCLUDE=process-id 


Use the SET AUDIT/NOEXCLUDE=process-id command to remove a 
process from the process exclusion list. (PIDs are not automatically 
removed from the process exclusion list when processes log out from the 
system.) 


Disabling Disk Resource Monitoring 
Resource monitoring is enabled, by default, on the disk volume containing 
the system security audit log file. To disable resource monitoring, execute 
the following SET AUDIT command: 


$ SET AUDIT/JOURNAL=SECURITY/RESOURCE=DISABLE 


If you disable disk resource monitoring, the only warning you receive from 
the audit server process regarding disk space is the following: 


AUDSRV-W-SYSJNLFULL, device full error on journal SECURITY; 
automatic server restart suppressed 


You must then execute the following SET AUDIT command to manually 
restart the audit server after you have recovered sufficient space on the 
disk volume: 


$ SET AUDIT/SERVER=START 
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6.5.3 Running Out of Virtual Memory 


Another potential security auditing resource problem is the exhaustion 
of process virtual memory. This problem is typically a due to the disk 
space limitation described in the previous section. When the disk volume 
associated with the security audit log file runs out of space, auditing 
messages destined for the log file are queued in memory until you take 
corrective action to free up space on the device. Depending upon the 
number of security audit messages that are generated while the disk 
volume is full, the audit server process could exhaust its process virtual 
memory. 


If its virtual memory has been exhausted, the audit server process, by 
default, forces a system failure to prevent further loss of security auditing 
messages. a 


Specify the following form of the SET AUDIT command to modify the 
action the audit server takes when process virtual memory has been 
exhausted. 


SET AUDIT/SERVER=FINAL_ACTION=keyword 

Select one of the keywords in Table 6-3 to specify the action the audit 
server process should take when it has run out of virtual memory: 
Table 6-3 Audit Server Final Action Keywords 

Keyword Description 





CRASH Forces a system failure if the audit server process runs out of 
virtual memory. This is the default. 


IGNORE_NEW __ Ignore new auditing messages until resources are available. Event 
messages leading up to the resource condition are saved; new 
messages are lost. 


PURGE_OLD Removes old event messages until resources are available. The 
most current messages are saved. / 





For example, the following command instructs the audit server process to 
ignore all new audit messages until adequate process virtual memory is 
available: 


$ SET AUDIT/SERVER=FINAL_ACTION=IGNORE_NEW 


6.5.4 Losing the Link to the Remote Security Archive File 
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If you are writing auditing messages to a remote security archive file, as 
described in Section 6.2.4, the link between the local and remote node can 
also be the source of resource problems. (See Area C in Figure 6—2.) 


No user intervention is required if the logical link to the remote node fails. 
The audit server broadcasts a warning message to all security operator 
terminals and attempts to reestablish the link every minute until the 
connection is made. 
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6.6 Auditing a Terminal Session 


You may need to audit an entire terminal session. If you set host to your 
own system and specify that a log file of the session be kept, the resulting 
log file will contain a record of the entire terminal session. For example, 
the following command keeps a record of the entire session in the log file 
APRIL15.LOG: 


$ SET HOST 0 /LOG=APRIL15.LOG 


Note that if you use the /LOG qualifier without including a file 
specification, the log information is stored in the file SETHOST.LOG. 


To use the SET HOST command, DECnet must be configured and started. 
You do not need a DECnet license; the DECnet license is only necessary 
to actually communicate with remote nodes. To use SET HOST in an 
environment without DECnet, you must configure a network database 
with no communications lines or remote nodes, and you must start the 
network. In the absence of supported communications equipment, the 
NETCONFIG.COM command procedure will perform these steps correctly. 
Details on these operations are provided in the VMS Networking Manual. 





6.6.1. Enforcing a Terminal Session Audit 


By using a special restricted account and appropriate command 
procedures, you can enforce auditing of terminal sessions for selected 
users. These users would need to log in to the special restricted account 
first and then in to their own account. The restricted account ensures that 
the session is audited. This section provides guidelines on how to set up 
the restricted account (named USER_AUDIT in this example) and includes 
samples of appropriate command procedures. 


The restricted account USER_AUDIT is set up as follows: 


UAF> ADD USER_AUDIT /FLAGS= (RESTRICTED, DISMAIL,DISNEWMAIL) - 
/LGICMD=SYS$SYSROOT: [USER_AUDIT]AUDITLOG - 
/DEV=SYS$SYSROOT: /DIR=[USER_AUDIT] - 

/NONETWORK /NOBATCH /UIC=xxx ... 


The AUDITLOG.COM command procedure enables auditing of the 
terminal session, as follows: 
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! AUDITLOG.COM - log in to specified account with terminal session 
! auditing enabled. 

! 

WRITE SYSSOUTPUT "Please log in to the account of your choice." 
WRITE SYSSOUTPUT "Your terminal session will be recorded." 

WRITE SYSSOUTPUT "" 


Acquire the intended username and save it in a temp file. Use it 
to name the log file, and pass it as the first line of input to 
LOGIN. 


READ/PROMPT="Username: " SYSSCOMMAND USERNAME 
PID = FSGETUPI (0, "PID") 

OPEN/WRITE OUTPUT USERNAME’ PID’ .TMP 

WRITE OUTPUT USERNAME 

CLOSE OUTPUT 

DEFINE/USER SYSSINPUT USERNAME’ PID’ . TMP 

SET HOST 0 /LOG=’USERNAME’ .LOG 

DELETE USERNAME’ PID’ .TMP;0 

LOGOUT 
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You must set up each account for which session auditing is to be enforced 
as follows: 


UAF> MODIFY username /FLAGS=RESTRICTED /NOLOCAL /NODIALUP - 
/LGICMD=SYSS$SYSROOT: [USER_AUDIT] CHECKAUDIT 


Because the captive login command procedure ensures that the login is 
coming from the USER_AUDIT account using a SET HOST command, the 
session is audited. 


You may also want to disable batch and network access for each user 
account to allow only local logins from the USER_AUDIT account, as 
follows: 


UAF> MODIFY username/FLAGS=RESTRICTED/NOLOCAL/NODIALUP/NOBATCH - 
/NONETWORK/LGICMD=SYS$SYSROOT: [USER_AUDIT] CHECKAUDIT 


The CHECKAUDIT.COM command procedure verifies that the user is 
logging in to the USER_AUDIT account, as follows: 


$ ! CHECKAUDIT.COM - ensure that the account is being logged in to 

$ ! with the session audit account. 

ae 

$ IF FSMODE () .NES. "INTERACTIVE" THEN EXIT 

$ ! 

$ ! Verify that the connection originated from the local node and 

$ ! from the USER_AUDIT account. 

$ ! 

$ IF FSLOGICAL ("SYSSNODE") .EQS. FSLOGICAL ("SYSSREM_NODE") - 
-AND. FSLOGICAL ("SYS$REM_ID") .EQS. "USER_AUDIT" - 
THEN GOTO OK 

$ WRITE SYSSOUTPUT "You may only log in to this account with ",- 
"the USER_AUDIT account." 

$ LOGOUT 
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S$ ! 

$ ! When the login has been verified, enable control-Y to 

S$ ! release the account, invoke the user’s LOGIN.COM, and turn 
$ ! control over to the user. 

$ ! 

SOK: 

$ SET CONTROL_Y 

$ IF FSSEARCH ("LOGIN.COM") .EQS. "" THEN EXIT 

$ @LOGIN 





6.7 Other Audit Data 


In addition to logging security alarms, VMS provides additional data 
useful in tracking system activity. The system accounting log contains 
records of all system job terminations, including all interactive, batch, 
and network jobs, as well as print jobs and other process terminations. 
Optionally, activations of all or selected images can also be recorded in 
the accounting log. Further information on the use of the accounting log 
is available in the Guide to Setting Up a VMS System and in the VMS 
Accounting Utility Manual. 


Most network operations, such as mail delivery and access to files from 
remote network nodes, initiate a network server job that creates a log file. 
This log file is normally named NETSERVER.LOG and is located in the 
default directory of the account under which the job ran. You may be able 
to use the contents of NETSERVER.LOG when tracking events initiated 
over the network. 
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After establishing appropriate security measures for your site, it is still 
vital to monitor your system for possible security breaches. Following are 
the most common forms of system attacks: 


Hunting for access lines 

Hunting for passwords 
Attempting a break-in 

Changing or creating UAF records 
Granting/stealing extra privileges 


Introducing apparently innocent software (Trojan horse software) that 
is intended to steal user passwords or do other damage to the system. 


Introducing worms in command procedures and programs to gain 
access to privileged accounts 


Scavenging disks 


Using a node as a gateway to other nodes 


This chapter describes how you can recognize when an attack on the 
system is in progress or has taken place and what countermeasures you 
can take. 


7.1 Indications of Trouble 


When your system is vulnerable and possibly under attack, your first 
indications may come from the following sources: 


Reports from users 
Monitoring the system 


Ongoing auditing applications 


The following sections outline problem indicators. 


7.1.1. Reports from Users 


User observations frequently point to system security problems. A user 
may contact you with the following situations: 


Files are missing. 


There are unexplained forms of last login messages, such as successful 
logins the user did not perform or unexplained login failures. 
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e A user cannot log in, suggesting the user password might have 
been changed since the last successful login, or some other form of 
tampering has occurred. 


e Break-in evasion appears to be in effect, and the user cannot log in. 


¢ Reports from the SHOW USERS command indicate that the user is 
logged in on another terminal when the user did not do so. 


e A disconnected job message appears during a login for a process the 
user never initiated. 


e Files exists in the user’s directories that the user did not create. 


¢ Unexplained changes have been found in the protection or ownership 
of user files. 


e Listings appear that are generated under the user name without the 
user requesting the listing. 


e A sudden reduction occurs in the availability of resources, such as 
dialup lines. 


Follow up promptly when one of these items is reported to you. You must 
confirm or deny that the condition exists. If you find the complaint is 
valid, seek a cause and solution. 


7.1.2 Monitoring the System 
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Section 5.9 lists those tasks that can help you detect potential security 
breaches on your system. The following list details possible warning signs 
you may uncover while performing the recommended tasks: 


¢ A user appears on the SHOW USERS report that you know could not 
be currently logged in. 


¢ You observe an unexplained change in the system load. 


¢ You discover media or program listings are missing or notice other 
indications that physical security has degraded. 


¢ Your locked file cabinet has been tampered with, and the list of 
authorized users has disappeared. 


¢ You find unfamiliar software in the system executable image library 
[SYSEXE] or in [SYSLIB]. 


¢ You observe unfamiliar images running when you examine the 
MONITOR SYSTEM report. 


¢ You observe unauthorized user names with SHOW USER. When 
you examine the listing that AUTHORIZE produces with the SHOW 
command, you find that those users have been given system access. 


¢ You discover PROXY users that you never authorized. 


e The accounting report reveals unusual amounts of processing time 
expended recently, suggesting outside access. 


¢ You observe unexplained batch jobs on the batch queues. 
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7.2.1 
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e You observe unexpected device allocations with the SHOW DEVICE 
command. 


e You observe a high level of processing activity at unusual hours. 


¢ The UIC-based protection or ACLs change on critical files. Identifiers 
are added, or holders of identifiers are added to the rights database. 


e There is high personnel turnover or low morale. 
All these conditions warrant further investigation. Some indicate that you 


already have a problem, some may have simple explanations, while others 
may indicate serious potential problems. 





Routine System Surveillance 


Accounting Log 


VMS provides a number of mechanisms that allow systematic surveillance 
of the activity in your system. Proper use of such mechanisms should help 
alert you to problems and allow you to intervene. This section describes 
the most important system surveillance mechanisms. 


Accounting logs generated by the VMS Accounting Utility can provide 
early indications of problems. Check your logs for the following: 


e Unfamiliar user names 


¢ Unfamiliar patterns of use, such as unusual activity for a particular 
time of day or day of week 


¢ Use of an unusual amount of resources 


¢ Unfamiliar sources of login, such as network nodes or remote terminals 


Security Auditing 


Use the DCL command SET AUDIT to enable alarms. Because security 
auditing affects system performance, enable security alarms only for 
the most important events. The following security alarm features are 
presented in order of decreasing priority and increasing system cost: 


1 Enable security auditing for LOGFAIL and BREAKIN. This is the best 
way to detect probing by outsiders (and insiders looking for accounts). 
All sites needing security should enable alarms for these events. 


2 Enable security auditing for LOGIN. Auditing successful logins from 
the more suspicious sources like REMOTE and DIALUP provides the 
best way to track which accounts are being used. An audit record is 
written before users logging in on a privileged account can disguise 
their identity. 


3 Enable the FILE=FAILURE security audit. This technique audits 
all file protection violations and is an excellent method of catching 
probers. 
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4 Apply ACL-based file access auditing to detect WRITE access to critical 


system files. The most important files to audit are shown in Table 7-1. 
Section 4.8.2 presents an example of how to establish security alarm 
ACEs. You may want to audit only successful access to these files to 
detect penetrations, or you may want to audit access failures to detect 
probing as well. 


Note that some of the files in Table 7—1 are written during normal 
system operation. For example, SYSUAF.DAT is written during each 
login, and SYSMGR.DIR is written when the system boots. 


Audit use of privilege to access files (either WRITE or 

all forms of access). Implement the security audit with 
FILE=(SYSPRV,BYPASS,READALL,GRPPRV). Note that this class 

of auditing can produce a large volume of output because privileges are 
often used in normal system operation for such tasks as mail delivery 

and operator backups. q 


Table 7-1 System Files Benefiting from ACL-Based File Access Auditing 


Device and Directory 


SYS$SYSTEM 


SYS$LIBRARY 
SYS$MANAGER 


SYS$SYSROOT 


File Name 


AUTHORIZE.EXE 

F11BXQP.EXE 

LOGINOUT.EXE 

DCL.EXE ( 
JOBCTL.EXE 

JBCSYSQUE.DAT 

SYSUAF.DAT 

NETPROXY.DAT 

RIGHTSLIST.DAT 

STARTUP.COM 

SECURESHR.EXE / 
AUDIT_SERVER.DAT ‘ 
SY*.COM 

VMSIMAGES.DAT 

[000000]SYSEXE.DIR 

[000000]SYSLIB.DIR 

[000000]SYS$LDR.DIR 

[000000]SYSMGR.DIR 





Handling a Security Breach 


There are four phases that security administrators experience while 
handling a security breach, whether the breach actually occurred or was 


attempted: 
1 Detection of a problem 
2 Identification of the perpetrator 
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3 Prevention of further security violations 


4 Repair of damage 


The following sections describe these phases for both attempted and 
successful break-ins. 


7.3.1. Unsuccessful Break-In Attempts 


7.3.1.1 


7.3.1.2 


7.3.1.3 


Unsuccessful break-in attempts include situations where someone has 
attempted to guess passwords or browse through files. 


Detection of the Unsuccessful Break-In Attempt 
You usually detect break-in attempts through the following sources: 


¢ Reports from users about unexplained login failures 
¢ Unusual system activity or unavailability of dialup lines 


e Security alarms for login failures, break-in detection, and file 
protection violations 


e Examination of the break-in database 


Identifying the Perpetrator 

Enabling file auditing simplifies identification of file browsers. If, however, 
browsing is being initiated from another node in the network, you must 
inspect the File Access Listener (FAL) logs that correspond to the times of 
the protection violations. Coordinate your investigation with the security 
administrator at the remote node. 


Identifying a perpetrator who is guessing passwords is considerably more 
difficult, especially when the source is anonymous, as from a dialup line. 
Usually, you must trade identification for prevention. Often the only way 
to positively identify an outsider attempting to enter the system requires 
that you permit further attempts while establishing the perpetrator’s 
identity. 


Prevention of Break-In Attempts 

The prevention phase for this kind of attack involves preventing the 
would-be intruder from actually gaining access to the system and making 
future attempts more difficult. 


Password Guessing 


To reduce the opportunities for successful password guessing, take the 
following steps: 


¢ Make certain your users choose appropriate passwords. Warn your 
users that someone is attempting entry. Consider use of the password 
generator (see Section 5.2.6.5). 


e Enable system passwords at the points of entry. While a minor 
inconvenience to your users, system passwords are the best protection 
against further probing. If you already had a system password 
enabled, change it (see Section 5.2.6.2). 
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7.3.1.4 


¢ Enable auditing of successful logins to catch the event if the intruder 
succeeds in getting in (see Section 7.2.2). 


File Browsing 


To reduce the opportunities for successful file browsing, take the following 
steps: 


e Ifyou can identify the perpetrator, take action as established at your 
site. 


e Warn your users about the importance of adequate protection of their 
files, and consider inspecting the protection of user files. 


e If file browsing from other nodes in the network becomes a persistent 
problem, eliminate the default FAL account and authorize individual 
users through proxy login accounts (see Section 8.6). 


Repair After an Unsuccessful Break-In 

No repair of files or data structures is necessary in this class of break- 
in. Typically, you have lost information to the browser. The value of the 
information determines the extent of the loss. 


7.3.2 Successful Break-In Attempts 
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7.3.2.1 


A successful security breach can include a successful password guessing 
scheme, theft or modification of information or system resources, and 
placement of damaging software on the system. A successful break-in may 
require a considerable amount of time to repair, depending upon the skill 
and intent of the perpetrator. 


identification of Break-In Perpetrator 

Identification is often the most difficult part of handling a break-in. First, 
you must establish whether the perpetrator is an authorized user or not. 
This determines the nature of the preventative measures that you will 
take. However, the distinction between insiders and outsiders may be 
difficult to achieve. 


Tradeoff Between Identification and Prevention 


You may have to make a tradeoff between a positive identification of the 
intruder and preventing future attacks. Often, the data available initially 
does not allow complete identification. If it is important to identify the 
perpetrator, you will often find it necessary to permit continued break-ins 
while you analyze the break-in activity. Step up your auditing. Consider 
planting traps in system procedures that are under your control (such as 
SYLOGIN.COM) to obtain additional information. Increase your system 
backup efforts to permit easier recovery if files become damaged. 


Identification of Outsiders 


Identifying external break-in perpetrators is particularly difficult, 
especially if they use any switched forms of communication (such as dialup 
lines or public data networks). DECnet-VAX provides many features to 
help you trace the activity through the network back to the source node. If 
a local terminal is involved, physical surveillance may be appropriate. 
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When a switched connection is invoived, one of the major computer 
security problems is the telephone system itself. Tracing a telephone 

or public data network connection is time-consuming. Chasing an intruder 
through the telephone system is likely to take months and will require 
the assistance of law enforcement authorities. The advent of independent 
long-distance telephone services compounds the problem by increasing the 
number of organizations with whom you must deal. 


As a result, identifying an outside intruder is usually worthwhile only 
when you have sustained substantial financial damage. In many cases, it 
may be more useful if you concentrate on preventing future recurrences of 
the problem. 


Prevention of Break-In Attempts 

The steps you must take to secure your system after a break-in depend on 
the nature and source of that break-in. This section describes these steps 
in order of priority. 


e¢ Secure your authorization files. Restore SYSUAF.DAT, 
NETPROXY.DAT, and RIGHTSLIST.DAT (if damaged) from backups. 
Alternatively, generate listings of the files and inspect them closely, 
looking for improper entries, additional privileges, and changed UICs. 
If you are unsure of when the UAF might have first been modified, 
inspect it carefully regardless of whether you are using a backup copy 
or proceeding with the existing one. 


¢ Change passwords. The perpetrator may have discovered passwords 
by browsing through files or from other nodes in the network and may 
be using seldom-accessed accounts for personal use. At a minimum, 
change passwords on all privileged accounts, and have your users 
appear in person to learn their new passwords. Do not use the same 
new password for all accounts. 


e Clean up your system software. A sophisticated penetrator may have 
planted ways to provide future access to the system even though you 
have taken the obvious steps of securing your system. Therefore, 
you may have to restore selected components of the VMS software 
from backups or from your VMS distribution kit. If the intruder was 
an outsider, the only critical component is LOGINOUT.EXE, which 
validates all entries to the system. 


However, if the intruder was an authorized user, restore all system 
files from backup copies. Authorized users can make use of a wide 
variety of “trap doors” in the executive (SYS.EXE), the file system 
(F11BXQP.EXE), DCL, and other system files. The penetrator may 
have planted damaging software in any piece of software or command 
procedure likely to be used by a privileged user. Thus, complete 
assurance of a “clean” system requires a wholesale restoration of files 
from backups. An alternate strategy is to restore trustworthy copies 
of the obvious targets of attack and rely on increased auditing for a 
period of time to catch suspicious events. 


¢ Tighten security. Consider implementing additional security features, 
such as system passwords, password generation, increased auditing, 
and more stringent file protection to prevent a recurrence. 
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7.3.2.3 


Repair After a Break-In 

Restore corrupted files. Decide whether it is appropriate to do a wholesale 
restoration of your system’s data, or repair problems as they are 
discovered. Look for modifications to file protection that would have 
created worm holes and for Trojan horses that were introduced into the 
system and may still reside there. 


8 Security fora DECnet Node 


Security in a networking environment is even more sensitive than security 
in a single system environment. It is also harder to achieve because of 
operational complexities and the decentralization of control that commonly 
exist in networks. The larger the network, the more difficult the problem 
of establishing control and communication between security administrators 
of the numerous nodes. 


This chapter provides direction on how security administrators can 
improve network security. Secure nodes and overall network security are 
even more important to system security than individual node operations 
and must be monitored and updated regularly. 


There are limitations in the degree of security any networking site can 
expect to achieve due to limitations currently present in networking 
technology. Being sensitive to potential problems can help you avoid 
operations that could increase the security exposure in your network. 
This chapter will help you recognize these problem areas and adjust your 
operations accordingly. 


This chapter assumes the reader is familiar with the information in the 
VMS Networking Manual. 


8.1 The Reference Monitor in a Network 


Chapter 2 introduces the reference monitor concept. This concept also 
applies to security in a network of interconnected computer systems. 
This section first extends the reference monitor concept to the network 
environment, then summarizes the special considerations that apply 
in a network, and finally makes the connection between the abstract 
components of the reference monitor concept and the real elements of a 
DECnet-VAX network. 


In a network, there is a subject on one computer, an object on another, 
and a network reference monitor that grants the subject access to the 
object, refers to an authorization database, and develops the required 
audit trail. Figure 8—1 shows this simplified view of secure access in a 
network environment. 
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Figure 8-1 Simple Diagram of Reference Monitor in a Network 
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While, for the most part, the network security mechanisms that Digital 
employs conform to the abstract model depicted in Figure 8-1, there are 
some differences. Consider a subject on one node in the network that 
attempts to access an object on a second node. Since each computer must 
have its own implementation of the reference monitor model, there will be 
a phantom object on the system with the real subject (the source machine) 
and a corresponding phantom subject on the system with the real object 
(the target machine). The resulting configuration resembles Figure 8-2. 
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Figure 8-2 Advanced Diagram of the Reference Monitor in a Network 
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There are three critical requirements for achieving security in a network 
environment: 


e There must be a correspondence between the real subject on the 
source machine and the phantom subject on the target machine. This 
correspondence must be managed by the two reference monitors and 
must be consistent with the security policy intended on the target 
machine (which is ultimately responsible for protecting the object). 


¢ The authorization database on the target machine must express an 
access authorization for a phantom subject that corresponds to the real 
subject on the source machine. 


¢ There must be a protected means of communication between the 
two reference monitors (source and target) so that correspondence 
between real and phantom subjects can be reliably established and 
authenticated. 


VMS provides mechanisms to help meet the first two requirements. 
Mechanisms for meeting the third requirement are discussed in 
Section 8.1.3. 
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8.1.1. Establishing Subject Correspondence 


VMS and DECnet-VAX provide several mechanisms for establishing a 
correspondence between a subject or process on a source node and another 
on a target node. Essentially, the default account mechanisms allow any 
subject on any node to be placed in correspondence with a default subject 
on a target node known as a default DECnet account. This subject can in 
turn gain access to objects on behalf of a requesting subject and return the 
required information. Because any subject can be placed in correspondence 
with a default subject on a target node, there is little selectivity or control 
in the establishment of the correspondence. 


Another alternative is the use of explicit or user name/password access 
control when establishing a subject at the target node. This mechanism 
restricts access to those objects accessible to the named user, but also 
causes users’ passwords to move about the network without effective 
protection. 


Finally, VMS offers proxy accounts as a means of establishing the 
correspondence between the real subject on the source node and the 
phantom subject on the target node. Section 3.2.2 describes proxy 
accounts. The proxy option requires the target reference monitor to 
maintain a table of source subjects (by user name and node name) and the 
corresponding local (target) user names. Then each request from a subject 
on a source node will be mapped into the creation of a subject representing 
the corresponding target user. This mechanism offers the explicit control 
associated with user name/password control, but more adequately protects 
the passwords. 


8.1.2 Specifying Authorizations 


The approach used to specify authorization for access to objects depends 
somewhat on the mechanism for establishing correspondence between 
subjects. The default account mechanisms essentially create anonymous 
subjects on the target node. As a result, objects that are to be made 
accessible to a default account must permit the WORLD user category full 
access, which leaves the object unprotected. 


If either explicit access control or proxy access is used to establish 
correspondence between subjects, the authorization can be granted to 

the target subject selected by the user name or proxy. In this case, the full 
range of VMS authorization mechanisms can be used. 


8.1.3 Protecting Communications 


It should be clear that the security of network operations depends mostly 
on the ability of source and target reference monitor mechanisms to 
communicate in a private, authenticated way. An intruder must not be 
allowed to observe passwords or to masquerade as a source node that has 
been granted proxy access. 
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Protected communication is outside the domain of VMS security. Users can 
achieve this protection through physical protection of the communication 
lines (available from third party vendors) or by protecting these lines using 
Digital’s Enhanced Ethernet Security System network encryption product, 
composed of DESNC security controllers and the VAX/KDC Ethernet 
security management software. 


While essential in high-security environments, network security 
measures such as conduits and encryption are useful at all sites. Many 
communication media, including most local area networks (LANs) like 
Ethernet, are so unprotected that an intruder or authorized user with a 
personal computer can easily read or forge any information passing over 
the network. 


8.1.4 Summary of VMS Network Security and the Reference Monitor 


To summarize, VMS provides, especially through the proxy mechanism, a 
vehicle for extending user authentication and authorization over a network 
in a secure, natural, and consistent manner. However, from a system point 
of view, the network security mechanisms are no better than the protection 
of the underlying communications. This can be critical in relatively open 
networks that process sensitive information. 


8.2 DECnet—VAX Accounts 


DECnet—VAX accounts permit certain types of access to your system from 
remote nodes without requiring them to specify account and password 
information. Instead, this information is specified in the DECnet-VAX 
executor and object databases. Like all accounts, these are controlled 
through the system authorization file using techniques similar to those 
used for restricted user accounts (see Section 5.8). 


Consider the following general guidelines when you set up accounts for 
DECnet—VAX use. Detailed examples are given in Section 8.5.3. 


e DECnet-—VAX currently has no requirement for a privileged default 
account. Keep the privileges for DECnet—VAX accounts to a minimum. 
Typically, this means you would only give TMPMBX and NETMBX to 
nonprivileged accounts. 


e UICs of the network nonprivileged accounts should be unique. 
Furthermore, the group code must exceed the system UIC group 
number to avoid granting the user the SYSTEM user category for file 
access. (Ensure this by using group codes greater than the SYSGEN 
parameter MAXSYSGROUP.) 


e Maintain the secrecy of passwords for DECnet—VAX accounts; they 
need not be known to users of your node or other nodes. Once the 
password is defined in the authorization file and the DECnet—-VAX 
databases, there will be no need to specify the password. 


e Set up the DECnet—VAX accounts with the following AUTHORIZE 
qualifiers: /FLAGS=(RESTRICTED,NODISUSER,NOCAPTIVE), 
/NOINTERACTIVE, and /NOBATCH. 
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e For any account that does not need to support remote file access, place 


the following command in the account’s login file to log out the account 


if remote file access is attempted: 
$ FALSCOMMAND == LOGOUT 


However, this technique only works when the FAL object is defined to 
execute the command procedure SYS$SYSTEM:FAL.COM. Since the 
DECnet—VAX default defines the FAL object to call FAL.EXE directly 
instead, you will probably need to execute the following DECnet-VAX 
command: 


NCP> DEFINE OBJECT FAL FILE FAL.COM 


This technique can be used with user accounts as well as with the 
network object accounts to prohibit remote file access by logging out 
any user who attempts it. Note that this technique shuts off only the 
remote file access, but allows access to other objects. This is preferable 
to specifying /NONETWORK in the user’s UAF, since that would deny 
all DECnet use. 


Section 8.5 describes how to create individual network accounts for each 
DECnet-VAX object required on the system. 


The DECnet—VAX Database 
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The DECnet—VAX node and circuit databases control how other computers 
are allowed to connect to your computer. Since a computer connection 
permits automated assaults on both your own security and that of any 
other computer in the network, it requires strict control. 


To promote the security of the databases, observe the following guidelines: 


¢ Define receive and transmit passwords for all nodes in the database. 
The receive password defined for a node needs to be known by the 
manager of that node only if that node can be adjacent. Wherever 
possible, the transmit and receive passwords should be different and 
not obvious. (Some operating systems do not permit this.) 


¢ Verification must always be enabled on any circuit that goes outside 
a locked computer room or to a machine with a different security 
environment. This is necessary to prevent the node adjacent to you 
from intercepting mail or circumventing a connection check for the 
originating node by pretending to be another node in the network. 
This is particularly important when proxy logins are permitted. 


¢ Do not define default access rights in the database for external nodes. 
A possible exception to this would be for a server or computer that is a 
dedicated front end for another computer. 

e In general, backup synchronous dialup should not be enabled for 


autoanswer. Systems that have incoming dialup for production 
purposes should control which nodes can connect. 
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8.4 Network Laws and Regulations 


Use of the network is restricted in many countries, either by law or by the 
contract with the major communications division of many governments 
known as the PTT. Always conform to these regulations. For example, 
several countries have laws to protect personal data from misuse, 
including restrictions on moving personal data across country boundaries. 
This would include moving or remotely accessing personnel databases 
and might also be interpreted to include such tasks as forwarding job 
applications. Germany has a law that forbids transmitting data for 
processing outside the country. 


Similarly, some European laws forbid anyone but the PTT from providing 
data transmission as a service to customers. In Germany, it is illegal to 
route data between the X.25 network and the leased line network. 


8.5 Specifying DECnet Object Accounts 


Network objects are system programs and user-written applications that 
permit communications among nodes in a DECnet-VAX network. As an 
important part of your overall system security plan, you should identify 
the set of network objects allowed access to your system and set up the 
appropriate access controls for each object. (For more information on 
network objects, see the VMS Networking Manual.) 


You can select one of the following mechanisms to control network access 
to your system: 


¢ Default DECnet account—A default DECnet account allows all 
network objects general access to the system. You can establish and 
maintain a default DECnet account for remote nodes if you consider 
your system a part of a low-security environment, such as a local area 
network of systems located within a building or site with no outside 
connections or dialup lines. 


¢ DECnet object accounts—A more secure alternative to the default 
DECnet account is the creation of network accounts for specific 
network objects. 


Creating individual accounts for network objects provides better 
accountability of remote access to the object. For example, you can 
create a captive login command procedure for the network object 
account that grants or denies access to the object based on the remote 
node name or user name. 


e Proxy account—lIf there is no default DECnet account on the system 
and no account created for the network object, you can still allow 
selected remote users proxy access to the object. (See Section 8.6 for 
more information about setting up a proxy account.) 


Sites with medium- to high-security requirements create and use proxy 
accounts as a means of denying all but a trusted set of remote users 
access to the local system. (Note, however, that it is still possible for 

a malicious person to impersonate a remote node in the network and 
gain all proxy access granted to users from that system.) 
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e Explicit access control string—For some sites with medium- to high- 
security requirements, both proxy access and access through network 
object-specific accounts are denied. Remote users can access protected 
network objects, however, by supplying access control information (the 
user name and password, typically) with the network request. 


For example, remote users with accounts on the local system can 
include the “username password” access control string in the file 
specification when attempting remote COPY operations, as shown in 
the following command: 


$ COPY DTROIT"WILSON MI2326G": :WORK1: [DISTRIBUTION] 
_§$ NOTICE.DAT * 


Depending upon the level of security required at your site, you can choose 
any of these access control techniques to protect access to your system 
from remote sources. 


The following sections summarize the network objects supplied with the 
VMS operating system and describe how to configure the objects using two 
different methods: automatically by using the DECnet-VAX configuration 
procedure NETCONFIG.COM, and manually by creating accounts for 
network objects with the Authorize Utility (AUTHORIZE) and modifying 
the network object database to recognize the object-specific accounts. 


8.5.1. Summary of Network Objects 


You should understand the function of the network objects supplied with 
the VMS operating system before you determine the access control to apply 
to them. This section provides a description of the most common network 
objects. 


TASK 


Through the default DECnet account, the TASK object allows arbitrary 
command procedures—including those which might be used in attempted 
break-ins—to be executed on your system. 


Note that if you do not allow default DECnet access on your system, or 
if you disable default DECnet access to the TASK object, you can allow 
remote user-written command procedures (tasks) to run on your system 
through the use of access control strings or proxy access. 


MAIL 


MAIL is an image that provides personal mail services for VMS systems. 
In most cases, you should allow the MAIL object general access to the 
system. 


FAL 


The file access listener (FAL) is the remote file access facility. FAL is an 
image that receives and processes remote file access requests for files at 
the local node. 
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Use of general FAL access is strongly discouraged. Open access aiiows 
general network access to any files marked world-accessible. It also allows 
remote users to create files in any directory with world WRITE access. 


Sites with high security requirements, or sites where it is difficult to 
recognize all the intended users, should not create a FAL account. To 
control which users gain access, these sites may establish one or more 
proxy accounts for specific purposes (see Section 8.6). 


PHONE 


PHONE is an image that allows online conversations with users on remote 
VMS systems. Note that if you allow default DECnet access to PHONE, 
anyone in the network can get a list of users currently logged in to the 
local system and attempt a login using the list of user names. 


NML 


NML is the Network Management Listener. Remote users with access 
to NML can use NCP TELL commands to gather and report network 
information from your DECnet databases. 


MIRROR 


MIRROR is an image that is used for particular forms of loopback testing. 
For example, MIRROR is run during the DECnet phase of the User 
Environment Test Package (UETP). 


VPM 


VPM is the VMS Performance Monitor Utility. Access to VPM is required 
to use the cluster monitoring features of the Monitor Utility (MONITOR). 


8.5.2 Configuring Network Objects Automatically 


The VMS operating system provides the command procedure 
NETCONFIG.COM in the SYS$MANAGER directory to automatically 
configure your system as a node in a DECnet network. Also, 
NETCONFIG.COM, when executed, provides you with a choice of defining 
either a default DECnet account on the system or separate network 
accounts for specific network objects. 


Typically, you run NETCONFIG.COM after installing a new version of 
the VMS operating system. If you have recently upgraded your system 
from a previous version of the operating system, and you want to remove 
default DECnet access on your system, you can execute the procedure 
NETCONFIG_UPDATE.COM, located in the SYS$UPDATE directory. 
NETCONFIG_UPDATE.COM provides most of the same features as 
NETCONFIG.COM, except that it does not purge the network databases 
before starting. 


Refer to the VMS Networking Manual and the VMS Upgrade and 
Installation Procedures manual for information about using the 
NETCONFIG.COM and NETCONFIG_UPDATE.COM network 
configuration procedures. 
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8.5.3 Configuring Network Objects Manually 
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If you choose not to execute the NETCONFIG.COM or NETCONFIG_ 
UPDATE.COM command procedure to configure or update the network 
objects on your system, you can perform the following operations to allow 
network access to specific objects: 


1 Create a top-level directory for the object (see Section 8.5.3.1). Specify 
a unique UIC for the directory owner. 


2 Using AUTHORIZE, create an account for the object (see 
Section 8.5.3.2) in the system user authorization file (SYSUAF). Use a 
generated password for the account. Note the name of the account and 
the password specified for the account; they are used in the next step 
of the procedure. 


3 Specify the account name and password for the object in the network 
object database (as described in Section 8.5.3.3). 


Repeat this procedure for each network object. When completed, remove 
default DECnet access from the executor database, and remove the default 
DECnet account from the SYSUAF (see Section 8.5.3.4). Finally, reboot 
the system to copy changes made to the permanent executor and object 
databases to the running system. 


Creating a Top-Level Directory for an Object 

When you create top-level directories for network object accounts, ensure 
that the UIC group is unique for each network object. The following 
example shows how to create a top-level directory for the MAIL object on 
the system disk: 


$ SET DEFAULT SYSSSPECIFIC: [000000} 
$§ CREATE/DIRECTORY [MAILSSERVER] /OWNER_UIC=[376,374] 


Table 8-1 lists the directory names, user names, and UICs used by 
the NETCONFIG.COM and NETCONFIG_UPDATE.COM command 
procedures to create accounts for specific network accounts. For 
consistency, you should specify the same information when manually 
creating network object accounts. 


Table 8-1 Network Object Defaults Used by NETCONFIG.COM 


Object Directory and 

Name User (Account) Name UIC 
MAIL MAIL$SERVER [376,374] 
FAL FAL$SERVER [376,373] 
PHONE PHONE$SERVER [376,372] 
NML NML$SERVER [376,371] 


(continued on next page) 
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Table 8-1 (Cont.) Network Object Defaults Used by NETCONFIG.COM 








Object Directory and 

Name User (Account) Name UIC 
MIRROR MIRRO$SERVER' [376,367] 
VPM VPM$SERVER [376,370] 





'Because AUTHORIZE enforces a user name limit of 12 characters, you must truncate the user 
name (and directory name) of the MIRROR object account to MIRRO$SERVER. 








8.5.3.2 Creating an Account for a Network Object 

The following example shows the commands you use to set up an account 
in AUTHORIZE for the MAIL object. Note that the user name and 
password that you specify must match the password defined for the object 


in the network database (described later in this section). 


$ RUN SYSSSYSTEM: AUTHORIZE 

UAF> ADD MAILSSERVER/OWNER=MAILSSERVER DEFAULT - 

UAF> /PASSWORD=MDU1294B/UIC=[376,374] /ACCOUNT=DECNET - 

UAF> /DEVICE=SYS$SPECIFIC: /DIRECTORY=[MAILSSERVER] —- 

UAF> /PRIVILEGE=(TMPMBX,NETMBX) /DEFPRIVILEGE=(TMPMBX,NETMBX) —- 
UAF> /FLAGS= (RESTRICTED, NODISUSER, NOCAPTIVE) /LGICMD=NL: - 

UAF> /NOBATCH /NOINTERACTIVE 


The AUTHORIZE command SHOW MAIL$SERVER displays the network 
account set up for the MAIL object, as shown in Example 8-1: 


Example 8-1 UAF Record for MAIL$SERVER Account 





Username: MAILSSERVER Owner: MAILSSERVER 

Account: MAILSSERVER DEFAULT UIC: [376,374] ([DECNET, MAILSSERVER] ) 
CLI: DCL Tables: 

Default: SYSSSPECIFIC: [MAILSSERVER] 

LGICMD: 


Restricted 
Mon Tue Wed Thu Fri Sat Sun 


Login Flags: 
Primary days: 
Secondary days: 

Primary 000000000011111111112222 Secondary 000000000011111111112222 
Day Hours 012345678901234567890123 Day Hours 012345678901234567890123 


Network: ##### Full access ###### ##### Full access ###### 
Batch: ----- No acceSS  -rrrr- 2 2 2 one No access ------ 
Local:  ----- No accesS ————s>- 0 so Se No access ------ 
Dialup: ----- No acceSS --——-— 2 2 2 see No accesS ==----- 
Remote:  ----- No accesS -——"""— «=== No access <------ 
Expiration: (none) Pwdminimum: 6 Login Fails: 0 
Pwdlifetime: (none) Pwdchange: (none) 

Last Login: (none) (interactive), (none) (non-interactive) 
Maxjobs: QO Fillm: 16 Bytlm: 12480 

Maxacct jobs: 0 Shrfillm: 0 Pbytlm: 0 

Maxdetach: QO BIOlm: 12 JTquota: 1024 

Prcelm: Q DIOlm: 6 WSdef: 180 

Prio: 4 ASTlm: 16 WSquo: 200 

Queprio: QO TQElm: 10 WSextent: 0 

CPU: (none) Enqlm: 20 Pgflquo: 25600 





(continued on next page) 
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Example 8-1 (Cont.) UAF Record for MAILS$SERVER Account 


Authorized Privileges: 
TMPMBX NETMBX 

Default Privileges: 
TMPMBX NETMBX 
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8.5.3.4 


Warning: 


Defining the Network Object Account Name and Password 

After you create the network account in AUTHORIZE, use the NCP 
DEFINE command to associate the user name and password of the account 
with the specified object in the network database, as follows: 


$ RUN SYSSSYSTEM:NCP 
NCP>DEFINE OBJECT MAIL USER MAILSSERVER PASSWORD MDU1294B 
NCP>EXIT 


Removing Default DECnet Access to the System 


Before deleting your default DECnet account, as described in this 
section, use the NCP command SHOW KNOWN OBJECTS and the 
Authorize Utility to verify that all network objects and layered 
products that use network objects have network accounts set up 
in the system user authorization file (SYSUAF). 


Once you have set up accounts for all the network objects needed, you ( 
should remove default DECnet access to the system. To do this, remove 

access to the DECnet account in the executor database and delete the 
DECNET account from the UAF. 


Removing Default DECnet Access 


Execute the following NCP commands to remove the default DECnet 
access from the network executor database: 


NCP>DEFINE EXECUTOR NONPRIVILEGED USER DEFAULT _DECNET / 
NCP>PURGE EXECUTOR NONPRIVILEGED PASSWORD 


The DEFAULT_DECNET user specified in the first command is a 
nonexistent user account that is specified for auditing purposes only. 
(A network login failure message is written to the security audit log file 


each time access to your system is attempted through the (nonexistent) 
DEFAULT_DECNET account.) 


Deleting the DECNET Account 


Using AUTHORIZE, remove the DECNET account from SYSUAF, as 
follows: 

$ SET DEFAULT SYSSSYSTEM 

$ RUN AUTHORIZE 


UAF> REMOVE DECNET 
UAF> EXIT 


Delete any files in the [DECNET] directory structure. , 


Security for a DECnet Node 
8.5 Specifying DECnet Object Accounts 





8.5.3.5 


Rebooting the System 

After configuring the desired network objects, reboot the system. The 
changes made to the permanent executor and object databases are copied 
to the system following the reboot. 





8.6 Proxy Logins 


As described in Section 3.2.2, you can authorize proxy access when you 
encounter situations where users on different nodes or in different groups 
want to share files on your system, and you are reluctant to give out 
passwords or to set the directory and file protection to WORLD:RWE. 
With proxy logins, there is no need for passwords to be embedded in 
commands to copy a file across the network. Also, there is no need for a 
file’s protection code to be set to allow the WORLD category of users READ 
access to transfer a file. The user enters the following form of the DCL 
command COPY: 


$ COPY remotenode::file-spec file-spec 


You can authorize a remote user access to a default proxy account and up 
to fifteen other proxy accounts. To copy a file over the network using proxy 
access from an account other than the default, the user includes the name 
of the proxy account in the access control string of the DCL command, as 
follows: 


$ COPY remotenode"proxyacct"::file-spec file-spec 


8.6.1. Setting Up Proxy Logins 


8.6.1.1 


Two utilities are used to set up proxy logins: AUTHORIZE and NCP. You 
might want to create a command procedure to assist you in implementing 
proxy access. 


For example, the command procedure could provide the following 
functions: 


e Check if proxy access is enabled for your system 

e Create a proxy account for sharing files 

e Grant a user access to a proxy account 

e Remove a user from access to a proxy account 

e Change the default proxy account for a user 

e List users authorized to access a proxy account 

Using the VMS Authorize Utility 

To set up proxy logins without using a command procedure, use 
AUTHORIZE to create or modify the network proxy authorization file, 
NETPROXY.DAT, that contains the names of all remote users allowed 
proxy access to the system and the names of all proxy accounts defined 


for the remote users. Note that the remote user can be specified either 
by user name or, for non-VMS systems that implement DECnet Phase IV, 
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8.6.1.2 


by UIC. The following commands are used to establish, modify, display, or 
remove records in the proxy authorization file: 


CREATE/PROXY 

ADD/PROXY node::remoteuser localuser[,...] 
LIST/PROXY 

MODIFY/PROXY node::remoteuser 
SHOW/PROXY node::remoteuser 
SHOW/PROXY * 

REMOVE/PROXY node::remoteuser 


Proxy Account Example 
When you want to set up a proxy account on your node for use by one or 
more users at other nodes, you must perform the following steps: 


1 


Decide on the purpose of the account. Decide the name of the local 
account and which network users will be admitted. 


If the local account does not exist, create it with AUTHORIZE; if the 
account does exist, examine it to ensure it is adequately restricted. 
Proxy accounts should be restricted so that they prohibit interactive 
users and batch jobs, which means they should permit only network 
logins. 


Review the privileges on the account. Generally avoid granting 
privileges to proxy login accounts. This practice provides a shield 
between systems in a network in the event one node is penetrated. 
The fact that proxy logins only provide admittance to nonprivileged 
accounts at other nodes may help contain the extent of damage if a 
penetration occurs on one system in the network. 


If the network proxy authorization file NETPROXY.DAT does not exist, 
create it with the AUTHORIZE command CREATE/PROXY. 


Allow as many remote users as necessary access to the proxy account Ny 
with the AUTHORIZE command ADD/PROXY. (Exercise caution when 
authorizing users. Ideally, you should receive a formal request from 

the security administrator at the remote site.) 


we 


Check the default protection on the directory, and customize it as 
necessary. 


Examine any command procedure used at login time and specified 

by /LGICMD. Make certain that it follows the recommendations in 
Section 5.8 for login command procedures in captive accounts. It 
should reside in a well-protected directory owned by a user other than 
the owner of the proxy account. It should prohibit WRITE access for 
those who use the account. 


Notify the security administrator at the remote node which users from 
that node have been authorized for access to your node. 
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In Example 8-2, the security administrator at the node WALNUT wants 
to create a general access account called GENACCESS. At the same time 
the manager wants to take steps to allow proxy logins by three users from 
the node BIRCH: KMAHOGANY, PSUMAC, and WPINE, as well as two 
users from the node WILLOW: RDOGWOOD and WCHERRY. Assume no 
network proxy authorization file currently exists. 


Example 8-2 A Sample Proxy Account 





$ SET DEFAULT SYSSSYSTEM 

$ RUN AUTHORIZE 

UAF> ADD GENACCESS /PASSWORD=WHYNADGUM/UIC=[236,043] - 
_UAF> /DEVICE=STAFFDEV/DIRECTORY=[GENACCESS] - 

_UAF> /OWNER="Security Mgmt"/ACCOUNT=SEC - 

_UAF> /FLAGS=(DISWELCOME, DISNEWMAIL,GENPWD,DISMAIL) - 
_UAF> /NOBATCH/NOINTERACTIVE/MAXDETACH=8 - 

_UAF> /LGICMD=LOGIN/MAXACCTJOBS=10 

user record successfully added 

identifier for value: [000236,000043] added to RIGHTSLIST.DAT 
UAF> CREATE/PROXY 

UAF> ADD/PROXY BIRCH::KMAHOGANY GENACCESS/DEFAULT 
record successfully added to NETPROXY.DAT 


UAF> ADD/PROXY BIRCH: :PSUMAC GENACCESS/DEFAULT 
record successfully added to NETPROXY.DAT 
UAF> ADD/PROXY BIRCH: :WPINE GENACCESS/DEFAULT 


record successfully added to NETPROXY.DAT 

UAF> ADD/PROXY WILLOW: : RDOGWOOD GENACCESS/DEFAULT 
record successfully added to NETPROXY.DAT 

UAF> ADD/PROXY WILLOW: : WCHERRY GENACCESS/DEFAULT 
record successfully added to NETPROXY.DAT 

UAF> SHOW/PROXY *::* 

Default proxies are flagged with a (D) 


BIRCH: : KMAHOGANY 
GENACCESS (D) 


BIRCH : : PSUMAC 
GENACCESS (D) 


BIRCH : sWPINE 
GENACCESS (D) 


WILLOW ::RDOGWOOD 
GENACCESS (D) 


WILLOW ::WCHERRY 
GENACCESS (D) 


UAF> EXIT 
{messages} 
$ DIRECTORY/SECURITY SYSSSTAFF: [000000]GENACCESS.DIR 


a 


3 DIRECTORY/SECURITY SYSS$STAFF: [GENACCESS] LOGIN.COM 
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8.6.1.3 


AUTHORIZE performs certain automatic maintenance functions on the 
NETPROXY.DAT proxy authorization file. Whenever the user name 
changes through a RENAME or COPY command, the associated change 
is made in NETPROXY. Similarly, when you remove an account from 
SYSUAE.DAT, all entries for which there is a matching local user name 
are removed from NETPROXY.DAT. 


Using the VMS Network Control Program (NCP) Utility 

Use NCP to control the overall use of proxy login with respect to the 
executor node and network objects. You can restrict the use of proxy logins 
on your system by specifying the NCP executor parameters INCOMING 
PROXY and OUTGOING PROXY, as shown in Table 8—2. 


Table 8-2 Executor Proxy Parameter Values 


Parameter Meaning 

INCOMING PROXY enabled Allows proxy login access from the remote node 
to the local node 

INCOMING PROXY disabled Prevents proxy login access from the remote 
node to the local node 

OUTGOING PROXY enabled Allows the local system to initiate proxy login 
access to the remote system 

OUTGOING PROXY disabled Prevents the local system from initiating proxy 


login access to the remote system 


By default, both incoming and outgoing proxy login access are enabled at 
the local system. 


You can also control proxy login access by network objects by setting the 
value of the object parameter PROXY in the OBJECT database. Specify 
proxy login access for a particular network object (such as MAIL or 
FAL) only when the desired proxy access is different from that defined 
in the EXECUTOR database. Refer to the VMS Networking Manual for 
information on using NCP to modify the executor and object databases. 


The control parameters are found in the executor and object databases. 
They each are part of the CHARACTERISTICS display that you can 
generate with the following command: 


$ RUN SYSSSYSTEM:NCP SHOW CHAR OBJ FAL 


The EXECUTOR database contains the INCOMING PROXY and 
OUTGOING PROXY parameters. These parameters are used to supply 
values for other parameters when they are not explicitly set up for a given 
node or object. These parameters make it easy to set up the DECnet-VAX 
configuration database. 


Proxy access will not function for nodes that have privileged or 
nonprivileged access control specified (parameters NONPRIVILEGED 

(or PRIVILEGED) USER, PASSWORD, and ACCOUNT). The concept 

of outbound proxy access conflicts with the concept of default outbound 
access control strings. This conflict occurs on the destination node. When 
a connect message containing non-null access control strings is received, 
the receiving node has no way of knowing whether those strings were 
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specified expiicitiy by the user or were deiaulis provided by the source- 
node operating system; when access control strings are passed in the 
connect message, they are used, and proxy access is inhibited. 


The USER, PASSWORD, and ACCOUNT parameters should rarely be 
used. They are still needed if default access is to be provided to nodes that 
cannot provide default inbound access control. VMS nodes are all capable 
of providing default inbound access control (in addition to proxy access) 
by setting the NONPRIVILEGED USER, PASSWORD, and ACCOUNT 
parameters in the EXECUTOR database. 


If outbound proxy access is implicitly set for a node to OUTGOING PROXY 
ENABLED in the EXECUTOR database, the USER, PASSWORD, and 
ACCOUNT parameters may still be set up for that node. In this case, 
outbound proxy access to that node will be inhibited since the DECnet— 
VAX connect message will contain non-null access control. 


The OBJECT database contains the PROXY parameter to control proxy 
access to and from individual objects in the network. The value for this 
parameter is taken from the EXECUTOR INCOMING PROXY and 
EXECUTOR OUTGOING PROXY parameters if it has not been given 
an explicit value or if a given object is not defined in the database. 


8.6.1.4 Conditions for Proxy Access 
For proxy access to be allowed, five conditions must be satisfied. If any of 
these conditions are not met, the default DECnet account is used. 


e The EXECUTOR DEFAULT PROXY parameter for the initiating node 
must be either BOTH or OUTGOING. 


¢ The OBJECT PROXY parameter for the initiating node must be either 
BOTH or OUTGOING. 


¢ The EXECUTOR DEFAULT PROXY parameter for the destination 
node must be either BOTH or INCOMING. 


¢ The OBJECT PROXY parameter for the destination node must be 
either BOTH or INCOMING. 


e¢ There must be an entry in NETPROXY.DAT on the destination node 
for the initiating node-user pair. For example, if the account HYDRA 
on the destination node of CRAB will permit proxy access for user 
CLAW on node LOBSTER, the listing of NETPROXY.DAT for node 
CRAB would include the following entry: 


LOBSTER::CLAW 
HYDRA (D) 


8.6.2 Special Proxy Access Considerations 


Proxy access is a selective merging of the authorization databases of the 
affected systems. Therefore, the security is only as good as the security of 
the least secure node involved. 
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8.6 Proxy Logins 


Although proxy access eliminates passwords going over the network, it is 
possible for a personal computer to bypass the proxy login mechanism by 
impersonating one of the authorized nodes. For this reason, the parameter 
INCOMING for proxy should not be used on vital nodes. Never set up 

a proxy account with privileges that could damage your system. (Proxy 
accounts should be unprivileged.) In general, timesharing nodes should 
not permit proxy access from standalone nodes. 


8.7 Sharing Files in the Network Environment 


The easiest way for a user to transfer a text file to another user is to 
invoke the VMS Mail Utility and send the user a copy of the file. This 
method is reasonably secure, since passwords need not be revealed, and 
the original protection of the file is not changed. The receiving user simply 
includes a new file name with the MAIL command EXTRACT/NOHEADER 
to place a copy in the user’s own directory. The copy automatically 
acquires the user’s default protection. The user would then use the MAIL 
command DELETE to remove the copy from the mail file. 


This procedure is inappropriate for nontext files, such as binary files. 
Alternate procedures become more useful once greater numbers of files 
and users become involved. 


Sites should discourage users from sharing passwords and changing file 
and directory protection codes to grant the WORLD category READ or 
EXECUTE access. Grant BYPASS or READALL privileges cautiously. 
The only secure method for sharing and exchanging files in the network 
environment is to set up proxy accounts and place ACLs on the directories 
and files. 


8.7.1 Remote Users Seek Access for a Single Task 
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A network manager may need to admit a number of users from outside 
nodes into a directory on the local node for a specific task. In this 
situation, the security administrator creates a proxy account and adds 
the proxy access to admit the outsiders into that one account. There may 
also be a number of users on the local node who need to share the files in 
this account’s directory. To provide that access while protecting the files 
from outsiders, place ACLs on the directory and files. 


Consider an example where a central depository is needed for sales update 
information that a number of users scattered throughout the corporation 
need to read. The security administrator at the node (BERTHA) where 
the files will reside, creates the special account SALES_READER.SALES_ 
READER is set up as a captive account with mail disabled. The default 
directory is [SALESINFO], which has the following default protection code: 


(S:RWED,O:RWED,G:R,W) 


Note that this protection code permits users in the same group as SALES_ 
READER on the home node BERTHA to read the files. Furthermore, only 
the users in the system category, the owner category, or those who have 
privileges that give them such access, can update the files in the directory. 
ACLs are used to further define the access, as shown later. 
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Next, the security administrator uses the AUTHORIZE command 
ADD/PROXY to add the proxy access for the outside users. For example, 
to extend proxy access to user JACKSON on node DEXTER and user 


GOODWIN on node BANGOR, the commands would be as follows: 


ADD/PROXY DEXTER:JACKSON SALES_READER/DEFAULT 
ADD/PROXY BANGOR::GOODWIN SALES_READER/DEFAULT 


If later it becomes clear that other users at the home node BERTHA need 
access and they do not belong to the same group as SALES_READER, 
ACLs could be added to the files in the directory [SALESINFO]. For 
example, suppose R_.GRANT needs CONTROL access to all the files and 
J_MAGOON needs READ access to ali the files. The following two DCL 
commands would define the ACL for the directory and then propagate it to 
all existing files: 


§ SET ACL/ACL=- 
$ ((IDENTIFIER=R_GRANT, OPTIONS=DEFAULT, ACCESS=CONTROL) , - 
~§ (IDENTIFIER=J_MAGOON, OPTIONS=DEFAULT, ACCESS=READ) ) - 
~§ [000000]SALESINFO.DIR 
$ SET FILE/ACL/DEFAULT *.*;* 


8.7.2 Remote Users from One Node Require Single Account Access 


When all (or nearly all) users at a remote node require access to one of 
your accounts, specify proxy access to the account with the following form 
of the AUTHORIZE command ADD/PROXY: 


ADD/PROXY remote-node::* local-account/DEFAULT 


Check to be certain that there are no guest accounts or other undesired 
accounts at the remote node. If you discover there are a few exceptions 
at the remote node, you cannot simply remove the extra users with 
REMOVE/PROXY commands because the preceding ADD/PROXY 
command creates a single entry in NETPROXY.DAT. Use the following 
technique to exclude specific individual users at the remote node from 
access to the proxy account: 


ADD/PROXY remote-node::* local-account/DEFAULT 
ADD/PROXY remote-node::FRED SPECIAL_ACCOUNT/DEFAULT 
ADD/PROXY remote-node::GEORGE SPECIAL_ACCOUNT/DEFAULT 


In the preceding example, all users on the remote node use the specified 
proxy account except users FRED and GEORGE who are directed to use 
the SPECIAL_ACCOUNT proxy account. 


8.7.3. Remote Users Require Multiple Account Access 


The preceding techniques work well when there are several outside users 
requiring access for one purpose. When a small number of outside users 
need access for multiple purposes involving files needing special protection, 
set up access to multiple proxy accounts and apply extensive ACLs. 
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For example, a large corporation with many branch offices might find 

it desirable to establish several proxy accounts for specific purposes for 
sharing. Assume the central corporation offices want to grant two key 
users from their two East Coast nodes READ and WRITE access to the 
project files for code name LEVIGRAY and READ only access to the 
BETSEYHARLOW project files. At the same time, there are three users 
from the West Coast who need READ access to those LEVIGRAY files and 
require READ and WRITE access to the BETSEYHARLOW files. Only two 
users from the central office will have full access rights to the LEVIGRAY 
files and two other users from headquarters will have full access rights to 
the BETSEYHARLOW files. For working purposes, the situation could be 
represented in tabular form as shown in Example 8-3. 


Example 8-3 Protected File Sharing in a Network 
Access Requirements to CENTRL: :PROJ: [DESGN_PROJECTS] 


Owned by [DESIGNERS, MGR] 
Users & Nodes 


Subdirectory LEVI Subdirectory BETSEY 
Project Files Project Files 
LEVIGRAY*.* BETSEYHARLOW* . * 

FRISCO: : ALBION R RW 

FRISCO: : ELTON R RW 

LA: : IRVING R RW 

CENTRL: : DIANTHA RWED NONE / 
CENTRL: :BRITTANIA RWED NONE \ 
CENTRL: : ALBERT NONE RWED 

CENTRL: :DELIA NONE RWED 

BOS: :AYLMER RW R 

WASH: : LAVINA RW R 


The following solution uses five proxy accounts in addition to the four 

local accounts on CENTRL, plus ACLs on the directory, subdirectories, and 

files. First, the security administrator at headquarters uses AUTHORIZE 

to create new proxy accounts on node CENTRL, for the remote users a 
ALBION, ELTON, IRVING, AYLMER, and LAVINA. These accounts 
should be captive, disallow mail, and be restricted to network access only. 
The accounts are even restricted to a subset of DCL through command 
language tables. The default directory should be [DESGN_PROJECTS] 
for each user. The manager decides it makes sense to put them into the 
DESIGNER group to match their proposed uses of the files. 


Presumably, accounts already exist for DIANTHA, BRITTANIA, ALBERT, 
and DELIA. They need not necessarily belong to the same group. They 
will be informed which device and directory to use for their work. 


= 


The next step is to add the proxy records to the network proxy 
authorization file with the following AUTHORIZE commands: 
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ADD/PROXY FRISCO::ALBION ALBION/DEFAULT 
ADD/PROXY FRISCO::ELTON ELTON/DEFAULT 
ADD/PROXY LA::IRVING IRVING/DEFAULT 
ADD/PROXY BOS::AYLMER AYLMER/DEFAULT 
ADD/PROXY WASH::LAVINA LAVINIA/DEFAULT 


The security administrator at node CENTRL places an ACL on the top- 
level directory for [DESGN_PROJECTS] with the following DCL command: 


$ SET ACL/ACL=(DEFAULT_PROTECTION,S:RWED,O,G,W) - 
_$ [000000]DESGN_PROJECTS.DIR 


This ensures that no one outside of the SYSTEM category of users can 
gain any UIC-based access to the files in the directory or any of the 
subdirectories unless they possess the BYPASS privilege. In fact, this 
restriction applies to those five users in the group DESIGNERS as well. 
The plan is for all files to possess ACLs that will admit the select group 
of users. It is desirable to propagate this protection code to all the files in 
this directory and its subdirectories. (The ACLs that will be placed on the 
files for further protection will take precedence when one of these users 
actually seeks access to a file.) 


Two subdirectories are created in [DESGN_PROJECTS]: 
¢ [DESGN_PROJECTS.LEVI] 
¢ [DESGN_PROJECTS.BETSEY] 


Next, the security administrator uses the VMS ACL Editor to place the 
following additional ACEs in the ACL for the top-level directory: 


DESGN_PROJECTS .DIR 


(IDENTIFIER=DIANTHA, OPTIONS=PROTECTED, ACCESS=EXECUTE) 
(IDENTIFIER=BRITTANIA, OPTIONS=PROTECTED , ACCESS=EXECUTE) 
(IDENTIFIER=ALBERT, OPTIONS=PROTECTED, ACCESS=EXECUTE) 
(IDENTIFIER=DELIA, OPTIONS=PROTECTED, ACCESS=EXECUTE) 
(IDENTIFIER=AYLMER, OPTIONS=PROTECTED, ACESS=EXECUTE) 
(IDENTIFIER=LAVINA, OPTIONS=PROTECTED, ACCESS=EXECUTE) 
(IDENTIFIER=ALBION, OPTIONS=PROTECTED, ACCESS=EXECUTE) 
(IDENTIFIER=ELTON, OPTIONS=PROTECTED, ACCESS=EXECUTE) 
(IDENTIFIER=IRVING, OPTIONS=PROTECTED, ACCESS=EXECUTE) 


These protected ACEs ensure that only the select nine users can access 
the top-level directory. Since no one receives WRITE or DELETE access 
to the top directory through the ACL, the directory and subdirectories are 
generally protected from deletion and renaming of files. (Of course, the 
SYSTEM category of user obtains WRITE and DELETE access through 
the UIC-based protection.) 


Next, the security administrator must create ACLs on the subdirectories. 
The ACEs that are required are shown for their respective subdirectories: 
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{[DESGN_PROJECTS] LEVI .DIR 


(IDENTIFIER=DIANTHA, OPTIONS=PROTECTED, ACCESS=READ+WRITE+EXECUTE+CONTROL) 
(IDENTIFIER=DIANTHA, OPTIONS=DEFAULT+PROTECTED , ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) 
(IDENTIFIER=BRITTANIA, OPTIONS=PROTECTED, ACCESS=READ+WRITE+EXECUTE+CONTROL) 
(IDENTIFIER=BRITTANIA, OPTIONS=DEFAULT+PROTECTED, ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) 
(IDENTIFIER=AYLMER, OPTIONS=PROTECTED, ACCESS=READ+WRITE) 

(IDENTIFIER=AYLMER, OPTIONS=DEFAULT+PROTECTED, ACCESS=READ+WRITE) 

(IDENTIFIER=LAVINA, OPTIONS=PROTECTED, ACCESS=READ+WRITE) 

(IDENTIFIER=LAVINA, OPTIONS=DEFAULT+PROTECTED, ACCESS=READ+WRITE) 

(IDENTIFIER=ALBION, OPTIONS=PROTECTED, ACCESS=READ) 

(IDENTIFIER=ALBION, OPTIONS=DEFAULT+PROTECTED, ACCESS=READ) 

(IDENTIFIER=ELTON, OPTIONS=PROTECTED, ACCESS=READ) 

(IDENTIFIER=ELTON, OPTIONS=DEFAULT+PROTECTED, ACCESS=READ) 

(IDENTIFIER=IRVING, OPTIONS=PROTECTED, ACCESS=READ) 

(IDENTIFIER=IRVING, OPTIONS=DEFAULT+PROTECTED, ACCESS=READ) 


[DESGN_PROJECTS] BETSEY .DIR 


(IDENTIFIER=ALBERT, OPTIONS=PROTECTED, ACCESS=READ+WRITE+EXECUTE+CONTROL) 
(IDENTIFIER=ALBERT, OPTIONS=DEFAULT+PROTECTED, ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) 
(IDENTIF IER=DELIA, OPTIONS=PROTECTED, ACCESS=READ+WRITE+EXECUTE+CONTROL) 
(IDENTIFIER=DELIA, OPTIONS=DEFAULT+PROTECTED , ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) 
(IDENTIFIER=ALBION, OPTIONS=PROTECTED, ACCESS=READ+WRITE) 

(IDENTIFIER=ALBION, OPTIONS=DEFAULT+PROTECTED, ACCESS=READ+WRITE) 

(IDENTIFIER=ELTON, OPTIONS=PROTECTED, ACCESS=READ+WRITE) 

(IDENTIFIER=ELTON, OPTIONS=DEFAULT+PROTECTED, ACCESS=READ+WRITE) 

(IDENTIFIER=IRVING, OPTIONS=PROTECTED, ACCESS=READ+WRITE) 

(IDENTIFIER=IRVING, OPTIONS=DEFAULT+PROTECTED, ACCESS=READ+WRITE) 

(IDENTIFIER=AYLMER, OPTIONS=PROTECTED, ACCESS=READ) 

(IDENTIF IER=AYLMER, OPTIONS=DEFAULT+PROTECTED, ACCESS=READ) 

(IDENTIFIER=LAVINA, OPTIONS=PROTECTED, ACCESS=READ) ( 
(IDENTIFIER=LAVINA, OPTIONS=DEFAULT+PROTECTED, ACCESS=READ) 


You will note that both preceding ACLs include two ACEs for each 
identifier. The first ACE controls the access to the subdirectory. It denies 
delete access for the protection of the subdirectory and is not propagated 
to all the files created in the subdirectory. The second ACE for each 
identifier will automatically propagate to all files added to their respective 
‘subdirectories because of the inclusion of the OPTIONS=DEFAULT option 
specification. Furthermore, the option PROTECTED ensures that all the 
ACKs are protected from deletion except by specific action. At this point, 
all the groundwork has been completed. Over time, files are added to the 
subdirectories. Thus, when the user LAVINA in Washington enters the 
following DCL command, the file LEVIGRAYMEM3.MEM is printed at 
node WASH: 


$ COPY CENTRL: : LEVIGRAYMEM3.MEM LP: 


However, any attempts by user LAVINA to edit the file 
BETSEYHARLOWMEMS8.MEM would fail, because user LAVINA is 
denied WRITE access through the ACL. 


If there were many users involved in this scheme, it would soon become 
worthwhile to grant additional identifiers to the users. For example, 
each user who would be allowed READ access to the files in the LEVI 
subdirectory might be given the identifier LEVILREADER, and so forth. 
The ACLs could then be shortened. 
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This chapter describes security concerns to security administrators on 
clustered VMS systems. You should be familiar with the information in 
the VMS VAXcluster Manual. 


The VMS VAXcluster Manual describes the person or team of persons who 
manage a VAXcluster as the cluster manager. The cluster manager is a 
specialized system manager. The security administrator for a VAXcluster 
generally requires the training and skills of the cluster manager. At some 
VAXcluster sites, the security administrator role is also performed by 

the cluster manager. At other sites, there may be one or more security 
administrators in addition to a cluster management team. 


When a site separates the security administrator function, coordination, 
cooperation, and communication are vital. As in previous chapters, this 
chapter uses the title of security administrator to refer to individuals 
who have the responsibility for system security, regardless of what other 
responsibilities they hold. 


9.1 Overview of Clusters and Security Considerations 


Clustered VMS systems refer to those systems using VMS hardware and 
software that permits sharing of disks, resources, and a common operating 
system among various VAX computers. The computers are said to be 
joined in a VAXcluster. There are two types of VAXclusters: common- 
environment and multiple-environment. A common-environment 
VAXcluster refers to one in which the operating system environment is 
identical on each member node. On a multiple-environment VAXcluster, 
each node has a unique environment. 


The fact that a node is part of a VAXcluster generally has little 
significance. Because each node in a VAXcluster appears to operate as 

a single system, all security features previously described apply equally 
well to any node in the cluster. When a security administrator implements 
the feature on one node of a common-environment cluster, all nodes are 
affected. Each cluster node mediates access by its subjects to all objects 
in the cluster. In effect, the cluster operates within a single security 
perimeter, with the reference monitor on each node acting as a gateway 
through that perimeter. 


There is, however, one area where the actions the cluster manager takes 
in setting up the VAXcluster can affect the security operations of the 
system. This concerns the creation and management of the authorization 
database. This chapter describes those security implications and provides 
recommendations. 
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Authorization Database Considerations 


Building a Common User Environment 


On a VAXcluster, there are advantages when all elements of the user 
authorization data exist in a common database. These authorization 
elements include the system and network user authorization files and the 
rights database, which are present on all VMS systems, and the optional 
autologin file, SYSALF.DAT, which some sites create with the VMS System 
Management (SYSMAN) Utility. (Section 5.2.8 describes how to use 
SYSMAN to create an autologin file.) 


If you create an autologin file, consider maintaining it in a common 
authorization database with your authorization files and rights database. 
On a clustered system, the autologin file must include the cluster node 
name as a prefix to the terminal name. For example, the terminal TTAO 
on node WILLOW would be represented as WILLOW$TTAO. 


The reasons for maintaining your authorization elements on a common 
disk are as follows: 


¢ Centralized management of the data is facilitated, which saves time 
and errors. 


¢ Acommon system disk allows you to maintain consistent, up-to-date 
system software for all nodes in the cluster. That is, if you want any of 
the three primary elements (NETPROXY, SYSUAF, or RIGHTSLIST) 
to be common for all nodes, you must have only one copy of each file 
in the cluster. This requirement reflects the fact that AUTHORIZE 
performs some automatic maintenance functions on the data. \ 


~ 


While you are not required to set up a common shared disk for these files, 
you are encouraged to do so. If you do not, remember that coordination is 
required in your choices for UICs, group numbers, and identifiers. They 
all must be unique. Each user should have the same UIC, group number, 
and set of identifiers defined on every node. 


Refer to the VMS VAXcluster Manual for guidelines for building a common 
user environment. The procedures depend on the initial state of your 
system. 


File Sharing Considerations 


When disks are shared, the file system works locally on each node to 
perform file protection checking. By setting up separate authorization files 
for each node, you could overlook the actual user privileges and access. 

A shared disk is no more protected than it is at its least protected node. 
If you maintain separate authorization files on each node in the cluster, 
ensure that user privileges are common across all copies of the UAF. 
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Beiween Ciusiter Nodges 


While VAXclusters offer special communication facilities for the most 
common operations (file sharing and lock management), other VMS 
features may require the use of DECnet to be used across a cluster. 

For example, you might need to access disks that are not cluster-accessible 
or use higher-level features available through DCL commands such as 
SHOW USERS. 


For maximum consistency in DECnet operations, set up a proxy database 
that maps users into their own accounts when they initiate DECnet 
operations. Thus, for each node in a common-environment cluster, you 
would add a proxy file entry using the following AUTHORIZE command: 


ADD/PROXY node::* */DEFAULT 


If you are running a multiple-environment cluster, you will need a more 
complex arrangement of proxies to cross-map users as they are authorized. 





In summary, security operations are enhanced on a VAXcluster when all 
authorization data resides on a common shared disk. The files of concern 
are: 


e SYSUAFDAT 

¢ NETPROXY.DAT 

¢ RIGHTSLIST.DAT 

¢ SYSALF.DAT (if it exists) 


Each user must have the same UIC, group number and set of identifiers 
defined on each cluster node. 


On a shared disk, the protection of a file from a specific user cannot 
effectively exceed the maximum access that user can gain from one of the 
nodes. 


In all respects, VMS security features operate the same on clustered 
systems as they do on nonclustered systems. 
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User Privileges 


ACNT Privilege 


This appendix describes all privileges available on VMS systems, including 
the abilities passed by each privilege and the users who should receive 
them. 


A user who has the ACNT privilege can create subprocesses or detached 
processes in which accounting is disabled. Thus, only such a privileged 
user can enter the DCL command RUN with the /NOACCOUNTING 
qualifier or inhibit accounting in the Create Process ($(CREPRC) system 
service. 


ALLSPOOL Privilege 


The ALLSPOOL privilege allows the user’s process to allocate a spooled 
device by executing the Allocate Device (SALLOC) system service or by 
using the DCL command ALLOCATE. 


The $ALLOC system service lets a process allocate, or reserve, a device for 
its exclusive use. A shareable mounted device cannot be allocated. 


Grant this privilege only to users who need to perform logical or physical 


I/O operations to a spooled device. Ordinarily, the privilege of allocating a 
spooled device is granted only to symbionts. 


The ALTPRI privilege allows the user’s process to: 
e Increase its own base priority 


e Set the base priority of another process to a value higher than that of 
the target process 


The base priority is increased by executing the Set Priority ($SETPRI) 
system service or the DCL command SET PROCESS/PRIORITY. As a rule, 
this system service lets a process set its own base priority or the base 
priority of another process. However, one process can only set the priority 
of a second process if one of the following conditions applies: 


¢ The process calling the $SETPRI system service has the same UIC as 
the target process. 


e The calling process has process control privilege (GROUP or WORLD) 
over the target process. 


Privileges 


A.1 User Privileges 


With ALTPRI, a process can create a process with a priority higher than 
its own. It creates such a process by using an optional argument to the 
Create Process ($CREPRC) system service or to the DCL command RUN. 


Do not grant this privilege widely; if unqualified users have the 
unrestricted ability to set base priorities, fair and orderly scheduling 
of processes for execution can easily be disrupted. 


A.1.4 BUGCHK Privilege 


The use of the BUGCHK privilege should be restricted to Digital-supplied 
system software that uses the VMS Bugcheck Facility. This privilege 
allows the process to make bugcheck error log entries. 


A.1.5 BYPASS Privilege 


The BYPASS privilege allows the user’s process read, write, execute, and 
delete access to all files, bypassing UIC-based and ACL protection. 


Grant this privilege with extreme caution, as it overrides all file protection. 
It should be reserved for use by either well-tested, reliable programs and 
command procedures or the system backup operation (see the Guide 

to Maintaining a VMS System for a discussion of backup operations). 
SYSPRV (see below) is adequate for interactive use, as it ultimately grants 
access to all files while still providing access checks. 


A.1.6 CMEXEC Privilege 


The CMEXEC privilege allows the user’s process to execute the Change 
Mode to Executive ($CMEXEC) system service. 


This system service lets a process change its access mode to executive 
mode, execute a specified routine, and then return to the access mode 
that was in effect before the system service was called. While in executive 
mode, the process is allowed to execute the Change Mode to Kernel 
($CMKRNL) system service. 


Grant this privilege only to users who need to gain access to protected and 
sensitive data structures and internal functions of the operating system. If 
unqualified users have unrestricted access to sensitive data structures and 
functions, the operating system and service to other users can be easily 
disrupted. Such disruptions can include failure of the system, destruction 
of the database, and exposure of confidential information. 


A.1.7 CMKRNL Privilege 
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The CMKRNL privilege allows the user’s process to execute the Change 
Mode to Kernel ($CMKRNL) system service. 


This system service lets a process change its access mode to kernel mode, 
execute a specified routine, and then return to the access mode that was 
in effect before the system service was called. 


Privileges 
A.1 User Privileges 


Graiit this privilege only to users who need to execute privileged 
instructions or who need to gain access to the most protected and sensitive 
data structures and functions of the operating system. If unqualified 
users have unrestricted use of privileged instructions and unrestricted 
access to sensitive data structures and functions, the operating system 
and service to other users can be easily disrupted. Such disruptions can 
include failure of the system, destruction of the database, and exposure of 
confidential information. 


A.1.8 DETACH Privilege 


Users can create detached processes that have their own UIC without the 
DETACH privilege, provided the users do not exceed their MAXJOBS and 
MAXDETACH quotas. However, the DETACH privilege becomes valuable 
when a user wants to specify a different UIC for the detached process. 
There is no restriction on the UIC that can be specified for a detached 
process if you have the DETACH privilege. Thus, there are no restrictions 
on the files and directories to which a detached process can gain access. 


DETACH allows the user’s process to create detached processes by 
executing the Create Process ($CREPRC) system service. Detached 
processes remain in existence even after the user who created them 
has logged off the system. 


An example of a detached process is the process created by the system for 
a user when the user logs in to the system. 


A.1.9 DIAGNOSE Privilege 


The DIAGNOSE privilege allows the user to run online diagnostic 
programs and to intercept and copy all messages written to the error 
log file. 


A.1.10 EXQUOTA Privilege 


The EXQUOTA privilege allows the space taken by the user’s files on given 
disk volumes to exceed any usage quotas set for the user (as determined 
by UIC) on those volumes. 


A.1.11 GROUP Privilege 


The GROUP privilege allows the user’s process to affect other processes in 
its own group by executing the following process control system services: 
Suspend Process ($SUSPND), Resume Process (SRESUME), Delete Process 
($DELPRC), Set Priority (SSETPRI), Wake (SWAKE), Schedule Wakeup 
($SCHDWKE), Cancel Wakeup (S$CANWAK), and Force Exit ($FORCEX). 
The user’s process is also allowed to examine other processes in its 

own group by executing the Get Job/Process Information ($GETJPI) 
system service. A user process with GROUP privilege can issue the SET 
PROCESS command for other processes in its group. 
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Privileges 
A.1 User Privileges 


GROUP privilege is not needed for a process to exercise control over, or 
to examine, subprocesses that it created or other detached processes of 
its UIC. You should, however, grant this privilege to users who need to 
exercise control over the processes and operations of other members of 
their UIC group. 


A.1.12 GRPNAM Privilege 


A.1.13  GRPPRV Privileg 


The GRPNAM privilege allows the user’s process to insert names into the 
logical name table of the group to which the process belongs and to delete 
names from that table by the use of the following logical name system 
services: Create Logical Name (SCRELNM) and Delete Logical Name 
($DELLNM). 


In addition, the privileged user can use the DCL commands ASSIGN and 
DEFINE to add names to the group logical name table, the DCL command 
DEASSIGN to delete names from the table, and the /GROUP qualifier of 
the DCL command MOUNT to share volumes among group members. 


Do not grant this privilege to all users of the system because it allows 
the user to create an unlimited number of group logical names. When 
unqualified users have the unrestricted ability to create group logical 
names, excessive use of system dynamic memory can degrade system 
performance. In addition, a user with the GRPNAM privilege can interfere 
with the activities of other users in the same group by creating definitions 
of commonly used logical names such as SYS$SYSTEM. 


e 


The GRPPRV privilege allows a process access to a file using the file’s 
SYSTEM protection field when the process’s group matches the group of 
the file owner. GRPPRV also allows a process to change the protection of 
any file whose owner group matches the process’s group. This privilege 
also allows a process to change the ownership of objects within the 
process’s group. 


Grant this privilege only to users who function as group managers. Note 
that if any member of a group holds any of the privileges in the “all” 
category, then any other member of that group who holds GRPPRV 
privilege can gain control of the system by indirectly acquiring that 
privilege. (The privileges in the “all” category have the potential to control 
the system and are described in Section 5.3.6.) 


A.1.14 LOG_IO Privilege 
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The LOG_IO privilege allows the user’s process to execute the Queue I/O 
Request ($QIO) system service to perform logical-level I/O operations. 
LOG_IO privilege is also required for certain device control functions, such 
as setting permanent terminal characteristics. 


~ 


A.1.15 MOUNT Privilege 


Privileges 
A.1 User Privileges 
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such as VAX Record Management Services. However, to increase their 
control over I/O operations and to improve the efficiency of I/O operations, 
skilled users sometimes prefer to handle directly the interface between 
their process and a system I/O driver program. They can do this by 
executing the Queue I/O Request system service; in many instances, the 
operation called for is a logical-level I/O operation. Note that logical level 
functions are permitted without LOG_IO privilege on a device mounted 
with the /FOREIGN qualifier and on nonfile-structured devices. 


Grant this privilege only to users who need it because it allows a process 
to access data anywhere on the selected volume without the benefit of any 
file structuring. If this privilege is given to unqualified users who have no 
need for it, the operating system and service to other users can be easily 
disrupted. Such disruptions can include the destruction of information 
on the system device, the destruction of user data, and the exposure of 
confidential information. 


The MOUNT privilege allows the user’s process to execute the mount 
volume QIO function. The use of this function should be restricted to 
system software supplied by Digital. 


A.1.16 NETMBX Privilege 


A.1.17 OPER Privilege 


The NETMBxX privilege allows the user to perform functions related to a 
DECnet computer network. Grant this privilege to general users who need 
to access the network. 


The OPER privilege allows the user to use the Operator Communication 
Manager (OPCOM) process, as follows: to reply to user’s requests, to 
broadcast messages to all terminals logged in, to designate terminals as 
operators’ terminals and specify the types of messages to be displayed 
on these operators’ terminals, and to initialize and control the log file of 
operators’ messages. In addition, this privilege lets the user set devices 
spooled and create and control queues. 


Grant this privilege only to the operators of the system. These are the 
users who respond to the requests of ordinary users, who tend to the needs 
of the system’s peripheral devices (mounting reels of tape and changing 
printer forms), and who attend to all the other day-to-day chores of system 
operation. (A nonprivileged user can log in on the console terminal to 
respond to operator requests, for example, to mount a tape.) 
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A.1.18 PFNMAP Privileg 


A.1.19 PHY_IO Privilege 


The PFNMAP privilege allows the user’s process to map to specific pages 
of physical memory or I/O device registers, no matter who is using the 
pages or registers. 


Exercise caution in granting this privilege. If unqualified users have 
unrestricted access to physical memory, the operating system and service 
to other users can be easily disrupted. Such disruptions can include failure 
of the system, destruction of the database, and exposure of confidential 
information. 


The PHY_IO privilege allows the user’s process to execute the Queue I/O 
Request ($QIO) system service to perform physical-level V/O operations. 


Usually, users’ I/O requests are handled indirectly by use of an I/O 
package such as VAX Record Management Services. However, to increase 
their control over I/O operations and to improve the efficiency of their 
applications, skilled users sometimes prefer to handle directly the interface 
between their process and a system I/O driver program. They can do this 
by executing the Queue I/O Request system service; in many instances, 
the operation called for is a physical-level I/O operation. 


Grant the PHY_IO privilege only to users who need it; this privilege ( 
should be granted even more carefully than the LOG_IO privilege. If 

this privilege is given to unqualified users who have no need for it, the 
operating system and service to other users can be easily disrupted. Such 
disruptions can include the destruction of information on the system 

device, the destruction of user data, and the exposure of confidential 
information. 


A.1.20 PRMCEB Privilege ( 
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The PRMCEB privilege allows the user’s process to create or delete 

a permanent common event flag cluster by executing the Associate 
Common Event Flag Cluster ($ASCEFC) or Delete Common Event Flag 
Cluster ($DLCEFC) system service. Common event flag clusters enable 
cooperating processes to communicate with each other and thus provide 
the means of synchronizing their execution. 


Do not grant this privilege to all users of the system because it allows 
the user to create an unlimited number of permanent common event 

flag clusters. A permanent cluster remains in the system even after the 
creating process has been terminated and continues to use up a portion of 
system dynamic memory. When many users have the unrestricted ability 
to create permanent common event flag clusters, the excessive use of 
system dynamic memory can degrade system performance. 


Privileges 
A.1 User Privileges 


A.1.21 PRMGBL Privilege 


The PRMGBL privilege allows the user’s process to create permanent 
global sections by executing the Create and Map Section ($CRMPSC) 
system service. In addition, the user with this privilege (plus CMKRNL 
and SYSGBL privileges) can use the VMS Install Utility. 


Global sections are shared structures that can be mapped simultaneously 
in the virtual address space of many processes. All processes see the same 
code or data. Global sections are used for reentrant subroutines or data 
buffers. 


Grant this privilege with care. If permanent global sections are not 
explicitly deleted, they tie up space in the global section and global page 
tables, which are limited resources. 


A.1.22 PRMMBX Privilege 


The PRMMBX privilege allows the user’s process to create or delete a 
permanent mailbox by executing the Create Mailbox and Assign Channel 
($CREMBX) system service or the Delete Mailbox ($DELMBX) system 
service. 


Mailboxes are buffers in virtual memory that are treated as if they were 
record-oriented I/O devices. A mailbox is used for general interprocess 
communication. 


Do not grant PRMMBX to all users of the system. Permanent mailboxes 
are not automatically deleted when the creating processes are deleted and, 
thus, continue to use a portion of system dynamic memory. 


A.1.23  PSWAPM Privilege 


The PSWAPM privilege allows the user’s process to control whether it can 
be swapped out of the balance set by executing the Set Process Swap Mode 
($SETSWM) system service. A process must have this privilege to lock 
itself in the balance set (that is, to disable swapping), or to unlock itself 
from the balance set (that is, to enable swapping). 


With this privilege, a process can create a process that is locked in the 

balance set (process swap mode disabled) by using an optional argument to 
the Create Process (SCREPRC) system service or, when the DCL command 
RUN is used to create a process, by using a qualifier of the RUN command. 


Grant this privilege only to users who need to lock a process in memory 
for performance reasons. Typically, this will be a real-time process. If 
unqualified users have the unrestricted ability to lock processes in the 
balance set, physical memory can be held unnecessarily and thereby 
degrade system performance. 


A-7 


Privileges 
A.1 User Privileges 


A.1.24 READALL Privilege 


The READALL privilege allows the process to bypass existing restrictions 
that would otherwise prevent the process from reading a file. However, 
unlike the BYPASS privilege, which permits writing and deleting, 
READALL only permits reading of the file and control operations (such as 
changing protection and writing the backup date). 


Grant this privilege to operators so they can perform system backups. 
The implications of this privilege are the same as those for the SYSPRV 
privilege. 


A.1.25 SECURITY Privilege 


The SECURITY privilege allows a process to perform security related 
functions such as enabling or disabling of security audits or setting the 
system password. 


Grant this privilege only to security administrators. Irresponsible users 
who obtain this privilege can subvert the system’s security auditing and 
can lock out users through improper application of system passwords. 


A.1.26 SETPRV Privilege 


A.1.27 SHARE Privilege 


The SETPRV privilege allows the user’s process to create processes whose 
privileges are greater than its own by executing the Create Process 
($CREPRC) system service with an optional argument, or by issuing 

the DCL command RUN to create a process. A user with this privilege can 
also execute the DCL command SET PROCESS/PRIVILEGES to obtain 
any desired privilege. 


Exercise the same caution in granting SETPRV as in granting any other 
privilege, since SETPRV allows the user to enable any or all privileges. 


The SHARE privilege allows processes to assign channels to devices 
allocated to other processes. 


Grant this privilege only to system processes such as print symbionts. 
This privilege would allow an irresponsible user to interfere with the 
operation of devices belonging to other users. 


A.1.28 SHMEM Privilege 
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The SHMEM privilege allows the user’s process to create global sections 
and mailboxes (permanent and temporary) in multiport memory if 

the process also has appropriate PRMGBL, PRMMBX, SYSGBL, and 
TMPMBX privileges. Just as in local memory, the space required for a 
multiport memory temporary mailbox counts against the buffered I/O byte 
count limit (BYTLM) of the process. 


Privileges 
A.1 User Privileges 


A.1.29 SYSGBL Privilege 


The SYSGBL privilege allows the user’s process to create system global 
sections by executing the Create and Map Section ($CRMPSC) system 
service. In addition, the user with this privilege (plus the CMKRNL and 
PRMGBL privileges) can use the VMS Install Utility. 


Exercise caution in granting this privilege. System global sections require 
space in the global section and global page tables, which are limited 
resources. 


A.1.30 SYSLCK Privilege 


The SYSLCK privilege allows the user’s process to lock systemwide 
resources with the Enqueue Lock Request (SENQ) system service. Grant 
this privilege to users who need to run programs that lock resources in the 
systemwide resource name space. 


Exercise caution in granting this privilege. Users who hold the SYSLCK 
privilege can interfere with the synchronization of system software and all 
other user software as well. 


A.1.31 SYSNAM Privilege 


The SYSNAM privilege allows the user’s process to insert names into the 
system logical name table and to delete names from that table by using the 
Create Logical Name ($CRELNM)and Delete Logical Name ($DELLNM) 
system services. This privilege also permits the creation of executive mode 
logical names. 


In addition, the user with this privilege can use the DCL commands 
ASSIGN and DEFINE to add names to the system logical name table, and 
can use the DEASSIGN command to delete names from the table. 


Grant this privilege only to the system operators or to system 
programmers who need to define system logical names (such as names for 
user devices, library directories, and the system directory). For example, 
to mount or dismount a system volume, which entails defining a system 
logical name, you must have the SYSNAM privilege. Note that a user with 
SYSNAM privilege could redefine such critical system logical names as 
SYS$SYSTEM and SYSUAF, thus gaining control of the system. 


A.1.32 SYSPRV Privilege 


The SYSPRV privilege allows the user to access objects by the SYSTEM 
protection field and to change the owner UIC and protection of a file. Even 
if a file is protected against system access, the user with the SYSPRV 

' privilege can change the file’s protection to gain access to it. 


Exercise caution in granting this privilege. Normally you would only 
grant this privilege to system managers and security administrators. 
If unqualified users have system access rights, the operating system 
and service to others can be easily disrupted. Such disruptions can 
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include failure of the system, destruction of the database, and exposure of 
confidential information. 


A.1.33 TMPMBX Privilege 


The TMPMBX privilege allows the user’s process to create a temporary 
mailbox by executing the Create Mailbox and Assign Channel ($CREMBX) 
system service. 


Mailboxes are buffers in virtual memory that are treated as if they were 
record-oriented I/O devices. A mailbox is used for general interprocess 
communication. Unlike a permanent mailbox, which must be explicitly 
deleted, a temporary mailbox is deleted automatically when it is no longer 
referenced by any process. 


Grant this privilege to all users of the system to facilitate interprocess 
communication. System performance is not likely to be degraded by 
permitting the creation of temporary mailboxes, because their number is 
controlled by limits on the use of system dynamic memory (BYTLM quota). 


A.1.34 VOLPRO Privilege 


The VOLPRO privilege allows the user to perform the following tasks: 


e Initialize a previously used volume with an owner UIC different from 
the user’s own UIC 


¢ Override the expiration date on a tape or disk volume owned by 
another user 


¢ Use the /FOREIGN qualifier to mount a Files-11 volume owned by 
another user 


e Override the owner UIC protection of a volume. 


The VOLPRO privilege permits control only over volumes that the user 
can mount or initialize. Volumes mounted with the /SYSTEM qualifier are 
safe from the user with the VOLPRO privilege as long as the user does not 
also have the SYSNAM privilege. 


Exercise extreme caution in granting the VOLPRO privilege. If 
unqualified users can override volume protection, the operating system 
and service to others can be disrupted. Such disruptions can include 
destruction of the database and exposure of confidential information. 


A.1.35 WORLD Privilege 
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The WORLD privilege allows the user’s process to affect other processes 
both inside and outside its group by executing the following process 
control system services: Suspend Process ($SUSPND), Resume Process 
($RESUME), Delete Process ($DELPRC), Set Priority ($SETPRI), Wake 
($WAKE), Schedule Wakeup ($SCHDWK), Cancel Wakeup ($CANWAK), 
and Force Exit ($FORCEX). The user’s process is also allowed to examine 
processes outside its own group. A user with WORLD privilege can issue 
the SET PROCESS command for all other processes. 


Privileges 
A.1 User Privileges 


To exercise control over subprocesses that it created or to examine these 
subprocesses, a process needs no special privilege. To affect or to examine 
other processes inside its own group, a process needs only the GROUP 
privilege. To affect or examine processes outside its own group, a process 
needs the WORLD privilege. 
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B _sUsing the User Data Areas in UAF Records 


You can use the $SETUAI (Set User Authorization Information) and 
$GETUAI (Get User Authorization Information) VMS system services to 
access UAF records for the storage and retrieval of up to 255 bytes of user 
data. See the VMS System Services Reference Manual for information 
about using the $SETUAI and $GETUAI item code UAI$_USER_DATA for 
this purpose. 


Note: The remainder of this appendix describes the method available 
in earlier versions of the VMS operating system for storing and 
retrieving user data in the UAF. Because the following method is 
no longer supported, Digital strongly recommends that you update 
any programs that use VMS RMS to manipulate user data in the 
UAF with the appropriate calls to $SETUAI and $GETUAI. 


The information in this appendix will be moved in a future 
revision of the manual to the VMS Obsolete Features Manual. 


B.1 Obsolete Method for Storing User Data in the UAF 


You can use VMS Record Management Services (RMS) to access UAF 
records for the storage and retrieval of up to 255 bytes of user data. 
The format of a UAF record is defined in the module $UAFDEF in 
SYS$LIBRARY:LIB.MLB. You may also find it useful to read the UAF$ 
section of SYS$LIBRARY:LIB.REQ, which contains commented structure 
definitions. 


Access UAF records sequentially through the following keys: 


e User name—tThe primary key is the user name (as specified to 
AUTHORIZE), a character field of size UAF$S_USERNAME located at 
relative offset UAF$T_USERNAME. 


¢ UIC—The secondary key is the UIC, located at relative offset 
UAF$L_UIC, consisting of two binary subfields of one word each. The 
subfields are named UAF$W_GRP (high-order word) and 
UAF$W_MEM (low-order word). 


To place data in a UAF record, take the following steps, which are 
designed to protect programs against future changes to the format of 
the UAF: 


1. Read the UAF record. 


2 Check the value of UAF$W_USRDATOFF. If it is zero, insert the 
current size of the record, as found in the VMS RMS record access 
block (RAB), into UAF$W_USRDATOFF. (In VMS Version 5.0, the 
system initializes this field to zero. Inserting the current size of the 
record has the effect of placing the user data at the end of the record. 
However, future changes to the UAF might require the system to fix 
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Note: 


eS 


the location of the user data. In this event, the system would initialize 
UAF$W_USRDATOFF to a nonzero value which the user must not 
change.) 


3 Insert the user data at the relative offset pointed to by UAF$W_ 
USRDATOFF. The data must take the form of a counted string, and 
the first byte must specify the number of bytes that follow. The total 
number of bytes must not exceed 255. 


4 Modify the size of the record in the RAB to reflect the addition of the 
user data area, unless the current size of the record exceeds the end 
of the user data area (that is, the contents of UAF$W_USRDATOFF 
plus the length of the user data). (In Version 5.0, the user data area, 
when specified as previously outlined, resides at the end of the record, 
so that modification of the RAB is essential. It is possible, however, 
that a future version of AUTHORIZE might fix the location of the user 
data area and its size (at 255 bytes), and locate additional system data 
after the user data. In this event, the user must not modify the size of 
the record.) 


5 Update the record. 


The user can now access the counted string by referring to UAF$W_ 
USRDATOFF. For additional updates, the user must not modify UAF$W_ 
USRDATOFF. However, if the record size changes, the user does modify 
the first byte of the counted string and the record size in the RAB, bearing 
in mind the considerations for future changes. 


Pa 


To avoid interfering with normal system operations, open the 

UAF to allow concurrent update; that is, specify to VMS RMS 
SHR=(GET,PUT,UPD,DEL). To update a record, you must lock it when 
you read it. 


The format of the UAF record and the way in which the system 
modifies it is subject to change in future versions of VMS. (For 
format changes, however, Digital will provide a utility to update 
old UAFs.) Adherence to the preceding guidelines will minimize 
reprogramming in the event of UAF record changes. 


pc 
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C Protection for VMS System Files 


The following display of protection codes and ownership corresponds 

to values that Digital supplies for the system files following a normal 
installation. Monitor these values regularly to ensure that no tampering 
has occurred. (The DCL commands DIRECTORY/SECURITY/OUTPUT 
and DIFFERENCES facilitate such checks.) The display in Example C—1 
was produced from the system manager’s account with the following DCL 
command: 


$ DIRECTORY/SECURITY/OUTPUT=SYSTEM FILES.LIS SYS$SYSROOT: [*...] 


Example C—1 Protection Codes and Ownership of System Files 





Directory SYSSSYSROOT: [SYSCOMMON] 


CDASLIBRARY .DIR;1 [1,4] (RWE, RWE, RE, RE) 
DECWSBOOK.DIR;1 [1,4] (RWE, RWE, RE, RE) 
DECWSDEFAULTS.DIR;1 

[1,4] (RWE, RWE, RE, RE) 
DECWSINCLUDE.DIR;1 [1,4] (RWE, RWE, RE, RE) 
SYSSKEYMAP .DIR;1 Pi 4] (RWE, RWE, RE, RE) 
SYSSLDR.DIR;1 [1,4] (RWE, RWE, RE, RE) 
SYSSSTARTUP .DIR;1 [1,4] (RWE, RWE, RE, RE) 
SYSCBI.DIR;1 [1,4] (RWE, RWE, RE, RE) 
SYSERR.DIR;1 [1,4] (RWE, RWE, RE, RE) 
SYSEXE.DIR;1 [1,4] (RWE, RWE, RE, RE) 
SYSFONT.DIR;1 [1,4] (RWE, RWE, RE, RE) 
SYSHLP .DIR;1 [1,4] (RWE, RWE, RE, RE) 
SYSLIB.DIR;1 [1,4] (RWE, RWE, RE, RE) 
SYSMAINT.DIR;1 [1,4] (RWE, RWE, RE, RE) 
SYSMGR.DIR;1 [1,4] (RWE, RWE, RE, RE) 
SYSMSG.DIR;1 [1,4] (RWE, RWE, RE, RE) 
SYSTEST.DIR;1 [1,4] (RWE, RWE, RE, RE) 
SYSUPD.DIR;1 [1,4] (RWE, RWE, RE, RE) 
VUESLIBRARY .DIR;1 [1,4] (RWE, RWE, RE, RE) 


Total of 20 files. 

Directory SYSSSYSROOT: [SYSCOMMON.CDASLIBRARY] 

DEFSTYLE.DDIF;1 [1,4] (RWED, RWED, RWED, RE) 
Total of 1 file. 

Directory SYSSSYSROOT: [SYSCOMMON . DECWSBOOK] 
BOOKREADER . DECWSBOOK; 1 


[1,4] (RWED, RWED, RWED, RE) 
LIBRARY . DECWSBOOKSHELF; 1 
[1, 4] (RWED, RWED, RWED, RE) 


Total of 2 files. 
Directory SYS$SYSROOT: [SYSCOMMON .DECWSDEFAULTS] 





(continued on next page) 
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Example C-1 (Cont.) Protection Codes and Ownership of System Files 





SYSTEM.DIR;1 [1,4] (RWE, RWE, RE, RE) 
USER.DIR;1 [1,4] (RWE, RWE, RE, RE) 


Total of 2 files. 
Directory SYSSSYSROOT: [SYSCOMMON . DECWS INCLUDE] 


COMPOBJ.H;1 [1,4] (RWED, RWED, RWED, RE) 
COMPOBJP .H;1 [1,4] (RWED, RWED, RWED, RE) 
COMPOSITE.H;1 {1,4] (RWED, RWED, RWED, RE) 
COMPOSITEP.H;1 [1,4] (RWED, RWED, RWED, RE) 
CONSTRAINP.H;1 [1,4] (RWED, RWED, RWED, RE) 
CONSTRAINT.H;1 [1,4] (RWED, RWED, RWED, RE) 
CONVERT .H;1 [1,4] (RWED, RWED, RWED, RE) 
CORE.H;1 [1,4] (RWED, RWED, RWED, RE) 
COREP.H;1 [1,4] (RWED, RWED, RWED, RE) 
CURSORFONT.H;1 ee a (RWED, RWED, RWED, RE) 
DECWDWTAPPLPROG.H;1 

[1,4] (RWED, RWED, RWED, RE) 
DECWDWTAPPLPROG.UIL;1 

[1,4] (RWED, RWED, RWED, RE) 
DECWDWIWIDGETPROG.H;1 

[1,4] (RWED, RWED, RWED, RE) 
DECWMHINTS.H;1 [1,4] (RWED, RWED, RWED, RE) 
DWTAPPL.H;1 [1,4] (RWED, RWED, RWED, RE) 
DWTAPPL.UIL;1 [1,4] (RWED, RWED, RWED, RE) 
DWIWIDGET.H;1 [1,4] (RWED, RWED, RWED, RE) 
EVENT.H;1 [1,4] (RWED, RWED, RWED, RE) 
INTRINSIC.H;1 [1,4] (RWED, RWED, RWED, RE) 
INTRINSICP.H;1 (head (RWED, RWED, RWED, RE) 
KEYSYM.H;1 [1,4] (RWED, RWED, RWED, RE) 
KEYSYMDEF .H;1 [1,4] (RWED, RWED, RWED, RE) 
OBJECT.H;1 [1,4] (RWED, RWED, RWED, RE) 
OBJECTP .H;1 [1,4] (RWED, RWED, RWED, RE) 
RECTOBJ.H;1 [1,4] (RWED, RWED, RWED, RE) 
RECTOBUP .H;1 [1,4] (RWED, RWED, RWED, RE) 
SELECTION.H;1 [1,4] (RWED, RWED, RWED, RE) 
SHELL.H;1 {1,4] (RWED, RWED, RWED, RE) 
SHELLP .H;1 [1,4] (RWED, RWED, RWED, RE) 
STRINGDEFS.H;1 [1,4] (RWED, RWED, RWED, RE) 
TRANSLATE .H;1 [1,4] (RWED, RWED, RWED, RE) 
VENDOR.H;1 [1,4] (RWED, RWED, RWED, RE) 
VENDORP .H;1 [1,4] (RWED, RWED, RWED, RE) 
WINDOWOBJ.H;1 [1,4] (RWED, RWED, RWED, RE) 
WINDOWOBUP .H;1 [1,4] (RWED, RWED, RWED, RE) 
X.H;1 [1,4] (RWED, RWED, RWED, RE) 
XATOM.H;1 [1,4] (RWED, RWED, RWED, RE) 
XLIB.H;1 [1,4] (RWED, RWED, RWED, RE) 
XMD.H;1 [1,4] (RWED, RWED, RWED, RE) 
XOS.H;1 [1,4] (RWED, RWED, RWED, RE) 
XPROTO.H;1 [1,4] (RWED, RWED, RWED, RE) 
XPROTOSTR.H;1 [1,4] (RWED, RWED, RWED, RE) 
XRESOURCE.H;1 [1,4] (RWED, RWED, RWED, RE) 
XUTIL.H;1 [1,4] (RWED, RWED, RWED, RE) 


Total of 44 files. 
Directory SYSSSYSROOT: [SYSCOMMON .MOMSSYSTEM] 
READ _ADDR.SYS;1 (376,375] (RWED, RWED, RWED, RE) 
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Total of 1 file. 

Directory SYSS$SYSROOT: [SYSCOMMON.SYS$KEYMAP ] 

DECW.DIR;1 [1,4] (RWE, RWE, RE, RE) 
Total of 1 file. 

Directory SYS$SYSROOT: [SYSCOMMON.SYSSKEYMAP . DECW] 


SYSTEM.DIR;1 [1,4] (RWE, RWE, RE, RE) 
USER.DIR;1 [1,4] (RWE, RWE, RE, RE) 


Total of 2 files. 
Directory SYSS$SYSROOT: [SYSCOMMON.SYSSKEYMAP .DECW. SYSTEM] 
AUSTRIAN GERMAN _LK201LG_DP.DECWSKEYMAP;1 


[1,4] (RWED, RWED, RWED, RE) 
AUSTRIAN_GERMAN LK201LG_TW.DECWSKEYMAP; 1 
[1,4] (RWED, RWED, RWED, RE) 
AUSTRIAN GERMAN LK201NG DP .DECWSKEYMAP; 1 
[1,4] (RWED, RWED, RWED, RE) 
AUSTRIAN GERMAN LK201NG_TW.DECWS$KEYMAP; 1 
[1,4] (RWED, RWED, RWED, RE) 
BELGIAN FRENCH _LK201LP_DP.DECWS$KEYMAP; 1 
[1,4] (RWED, RWED, RWED, RE) 
BELGIAN FRENCH LK201LP_TW.DECWSKEYMAP;1 
[1,4] (RWED, RWED, RWED, RE) 
BRITISH LK201LE DP .DECWSKEYMAP; 1 
[1,4] (RWED, RWED, RWED, RE) 
BRITISH LK201LE_TW.DECWSKEYMAP;1 
[1,4] (RWED, RWED, RWED, RE) 
CANADIAN FRENCH LK201LC_DP.DECWSKEYMAP; 1 
[1,4] (RWED, RWED, RWED, RE) 
CANADIAN FRENCH _LK201LC_TW.DECWSKEYMAP; 1 
[1,4] (RWED, RWED, RWED, RE) 
DANISH _LK201LD DP.DECWSKEYMAP; 1 
[1,4] (RWED, RWED, RWED, RE) 
DANISH _LK201LD TW.DECWSKEYMAP; 1 
[1,4] (RWED, RWED, RWED, RE) 
DANISH _LK201RD DP.DECWS$KEYMAP; 1. 
[1,4] (RWED, RWED, RWED, RE) 
DANISH _LK201RD_TW.DECWSKEYMAP; 1 
[1,4] (RWED, RWED, RWED, RE) 
DUTCH_LK201LH_DP.DECWSKEYMAP ; 1 
[1,4] (RWED, RWED, RWED, RE) 
DUTCH LK201LH_TW.DECWSKEYMAP; 1 
[1,4] (RWED, RWED, RWED, RE) 
DUTCH_LK201NH.DECWSKEYMAP ; 1 
{1, 4] (RWED, RWED, RWED, RE) 
FINNISH_LK201LF_DP.DECWSKEYMAP; 1 
[1,4] (RWED, RWED, RWED, RE) 
FINNISH _LK201LF_TW.DECWSKEYMAP; 1 
[1,4] (RWED, RWED, RWED, RE) 
FINNISH_LK201NX_DP.DECWSKEYMAP; 1 ; 
[1,4] (RWED, RWED, RWED, RE) 
FINNISH LK201NX TW.DECWSKEYMAP;1 
Z ~ [1,4] (RWED, RWED, RWED, RE) 
FLEMISH LK201LB DP.DECWSKEYMAP;1 
a = [1,4] (RWED, RWED, RWED, RE) 
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FLEMISH_LK201LB_ TW.DECWSKEYMAP;1 


[1,4] (RWED, RWED, RWED, RE) 
ICELANDIC_LK201LU_DP.DECWSKEYMAP; 1 

[1,4] (RWED, RWED, RWED, RE) 
ICELANDIC_LK201LU_TW.DECWSKEYMAP;1 

[1,4] (RWED, RWED, RWED, RE) 
ITALIAN_LK201LI_DP.DECWSKEYMAP ; 1 

[1,4] (RWED, RWED, RWED, RE) 
ITALIAN_LK201LI_TW.DECWSKEYMAP ; 1 

(1, 4] (RWED, RWED, RWED, RE) 
NORTH_AMERICAN_LK201LA.DECWSKEYMAP ; 1 

[1,4] (RWED, RWED, RWED, RE) 
NORWEGIAN _LK201LN_DP.DECWSKEYMAP; 1 

[1,4] (RWED, RWED, RWED, RE) 
NORWEGIAN_LK201LN_TW.DECWSKEYMAP; 1 

[1,4] (RWED, RWED, RWED, RE) 
NORWEGIAN _LK201RN_DP.DECWSKEYMAP;1 

[1,4] (RWED, RWED, RWED, RE) 
NORWEGIAN _LK201RN_TW.DECWSKEYMAP ;1 

[1,4] (RWED, RWED, RWED, RE) 
PORTUGUESE_LK201LV.DECWSKEYMAP; 1 

[1,4] (RWED, RWED, RWED, RE) 
SPANISH_LK201LS_DP.DECWSKEYMAP;1 

[1,4] (RWED, RWED, RWED, RE) 
SPANISH _LK201LS_TW.DECWSKEYMAP;1 

[1,4] (RWED, RWED, RWED, RE) 
SWEDISH_LK201LM_DP.DECWSKEYMAP;1 

[1,4] (RWED, RWED, RWED, RE) 
SWEDISH_LK201LM_TW.DECWSKEYMAP; 1 

[1,4] (RWED, RWED, RWED, RE) 
SWEDISH_LK201NM_DP.DECWSKEYMAP;1 

[1,4] (RWED, RWED, RWED, RE) 
SWEDISH _LK201NM_TW.DECWSKEYMAP; 1 

[1,4] (RWED, RWED, RWED, RE) 
SWISS FRENCH _LK201LK_DP.DECWSKEYMAP; 1 

[1,4] (RWED, RWED, RWED, RE) 
SWISS_FRENCH_LK201LK_TW.DECWSKEYMAP; 1 

[1,4] (RWED, RWED, RWED, RE) 
SWISS_GERMAN LK201LL_DP.DECWSKEYMAP;1 

[1,4] (RWED, RWED, RWED, RE) 
SWISS GERMAN LK201LL_TW.DECWSKEYMAP;1 

[1,4] (RWED, RWED, RWED, RE) 
UK_LK201RE.DECWSKEYMAP; 1 

[1,4] (RWED, RWED, RWED, RE) 
US_LK201RE.DECWSKEYMAP ; 1 

[1,4] (RWED, RWED, RWED, RE) 


Total of 45 files. 
Directory SYSSSYSROOT: [SYSCOMMON.SYSSLDR] 
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CLUSTRLOA. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
CNDRIVER. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
CONINTERR. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
CPULOA.EXE;1 {1,4] (RWED, RWED, RWED, RE) 
CRDRIVER. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
CSDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
CTDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
CVDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
CWDRIVER. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
DBDRIVER. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
DDDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DDIFS$RMS_EXTENSION.EXE; 1 

[1,4] (RWED, RWED, RWED, RE) 
DKDRIVER.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
DLDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DMDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DQDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DRDRIVER. EXE; 1 (1, 4] (RWED, RWED, RWED, RE) 
DSDRIVER. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
DUDRIVER. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
DVDRIVER. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
DXDRIVER. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
DYDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DZDRIVER.EXE;1 {1,4] (RWED, RWED, RWED, RE) 
ERRORLOG. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
ESDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ETDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
EVENT _FLAGS_AND_ASTS.EXE;1 

[1,4] (RWED, RWED, RWED, RE) 
EXCEPTION. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
EXEC_INIT.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
FBDRIVER. EXE; 1 (1, 4] (RWED, RWED, RWED, RE) 
FPEMUL.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
FYDRIVER .EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
GAADRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
GABDRIVER.EXE; 1 (1, 4] (RWED, RWED, RWED, RE) 
GBBDRIVER.EXE; 1 (1, 4] (RWED, RWED, RWED, RE) 
GCADRIVER. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
GCBDRIVER. EXE; 1 (1, 4] (RWED, RWED, RWED, RE) 
IKDRIVER. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
IMAGE_MANAGEMENT .EXE; 1 . 

[1,4] (RWED, RWED, RWED, RE) 
IMDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
INDRIVER. EXE; 1 [4 (RWED, RWED, RWED, RE) 
IO_ROUTINES.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
LADRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
LCDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
LIDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
LMF$GROUP_TABLE.EXE;1 

[1,4] (RWED, RWED, RWED, RE) 
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LOCKING. EXE; 1 {1,4] 
LOGICAL NAMES .EXE;1 

[1,4] 
LPDRIVER.EXE;1 {1, 4] 
LTDRIVER.EXE;1 {1,4] 
MBXDRIVER.EXE;1 {1,4] 
MESSAGE_ROUTINES . EXE; 1 
| [1,4] 
MKDRIVER.EXE;1 {1,4] 
NDDRIVER. EXE; 1 {1, 4] 
NETDRIVER.EXE;1 {1,4] 
NODRIVER. EXE; 1 {1,4] 
PADRIVER.EXE;1 {1,4] 
PAGE MANAGEMENT . EXE; 1 

[1,4] 
PBDRIVER.EXE;1 {1, 4] 
PDDRIVER.EXE;1 [1,4] 
PEDRIVER.EXE;1 [1,4] 
PIDRIVER.EXE;1 [1,4] 
PKNDRIVER.EXB;1 {1,4] 
PKSDRIVER. EXE; 1 {1,4] 


PRIMITIVE IO.EXE;1 [1,4] 
PROCESS MANAGEMENT .EXE; 1 


[1,4] 
PUDRIVER.EXE;1 [1,4] 
PYDRIVER. EXE; 1 [1,4] 
RECOVERY UNIT SERVICES.EXE;1 
{1,4] 
RMS. EXE; 1 [1,4] 
RTTDRIVER. EXE; 1 [1,4] 
RXDRIVER. EXE; 1 [1,4] 
SCSLOA.EXE;1 [1,4] 
SECURITY .EXE;1 [1,4] 
SYSS$NETWORK_SERVICES.EXE;1 
[1,4] 
SYS$TRANSACTION SERVICES.EXE;1 
{1, 4] 
SYS.EXE;1 (ia) 
SYSDEVICE.EXE; 1 [1,4] 
SYSGETSYI.EXE;1 [1,4] 
SYSLDR_DYN.EXE;1 [1,4] 
SYSLICENSE.EXE;1 [1,4] 
SYSLOA410.EXE;1 [1,4] 
SYSLOA41A.EXE;1 [1,4] 
SYSLOA41D.EXE;1 [1,4] 
SYSLOA41W.EXE;1 [1,4] 
SYSLOA420.EXE;1 [1,4] 
SYSLOA42D.EXE;1 [1,4] 
SYSLOA42W.EXE;1 [1,4] 
SYSLOA60.EXE;1 ty, 4) 
SYSLOAG640 .EXE;1 [1,4] 
SYSLOA64D.EXE;1 [1,4] 
SYSLOA650.EXE;1 [1,4] 
SYSLOA65D.EXE;1 [1,4] 
SYSLOA730.EXE;1 [1,4] 
SYSLOA750.EXE;1 [1,4] 
SYSLOA780.EXE;1 [1,4] 
SYSLOA790.EXE;1 [1,4] 


(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
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SYSLOA8NN.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
SYSLOA8PS.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
SYSLOA8SS.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
SYSLOA9CC.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
SYSLOAQRR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
SYSLOAUV1.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
SYSLOAUV2.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
SYSLOAWS1.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
SYSLOAWS2 .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
SYSLOAWSD .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
SYSTEM DEBUG.EXE;1 [1,4]. (RWED, RWED, RWED, RE) 
SYSTEM PRIMITIVES .EXE;1 

[1,4] (RWED, RWED, RWED, RE) 
SYSTEM_SYNCHRONIZATION.EXE;1 

[1,4] (RWED, RWED, RWED, RE) 
SYSTEM_SYNCHRONIZATION_MIN.EXE;1 

[1,4] (RWED, RWED, RWED, RE) 
SYSTEM_SYNCHRONIZATION_UNI.EXE;1 

[1,4] (RWED, RWED, RWED, RE) 
TFDRIVER. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
TMDRIVER.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
TSDRIVER.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
TTDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
TUDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
TVDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
TWDRIVER.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
VAXEMUL . EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
VMSS$SYSTEM IMAGES.DATA;1 

[1,4] (RWED, RWED, RWED, RE) 
WORKING SET MANAGEMENT .EXE;1 

[1,4] (RWED, RWED, RWED, RE) 
WPDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
WSDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
XADRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
XDDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
XEDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
XFDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
XGDRIVER.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
XIDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
XMDRIVER. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
XQDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
YCDRIVER. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
YEDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
YFDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
YIDRIVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 


Total of 136 files. 


Directory SYSS$SYSROOT: [SYSCOMMON.SYSSSTARTUP ] 
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DNSS$CLERK_STARTUP .COM;1 


[1,4] 
DNSS$CLERK_STOP .COM;1 

[1,4] 
LICENSE_CHECK.EXE;1 

[1,4] 
VMSSBASEENVIRON-050_LIB.COM;1 

[1,4] 
VMS$BASEENVIRON-050_SMISERVER.COM;1 

[1,4] 
VMSSBASEENVIRON-050_VMS.COM;1 

[1,4] 
VMSSCONFIG-050_AUDIT_SERVER.COM;1 

[1,4] 
VMSSCONFIG-050_ CACHE_SERVER.COM;1 

{1,4} 
VMSSCONFIG-050_CSP .COM;1 

[1,4] 
VMSSCONFIG-050_ERRFMT.COM;1 

[1,4] 
VMSS$CONFIG-050 JOBCTL.COM;1 

[1,4] 
VMSSCONFIG-050_LMF.COM; 1 

[1,4] 
VMSS$CONFIG-050_OPCOM.COM; 1 

[1,4] 
VMSSCONFIG-050_VMS.COM; 1 

[1,4] 
VMSSINITIAL-050 CONFIGURE .COM;1 

[1,4] 
VMSSINITIAL-050_LIB.COM;1 

[1,4] 
VMSSINITIAL-050_VMS.COM; 1 

[1,4] 
VMSS$LAYERED . DAT; 1 [1,4] 
VMSSLPBEGIN-050_STARTUP.COM;1 

[1,4] 
VMSSPHASES .DAT;1 [1,4] 
VMSSSYSFILES-050_VMS.COM;1 

[1,4] 
VMSSVMS .DAT;1 [1,4] 


Total of 22 files. 


Directory SYS$SYSROOT: [SYSCOMMON.SYSERR] 


ERRSNAP .COM;1 {1,4} 
Total of 1 file. 





(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
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Directory SYSSSYSROOT: [SYSCOMMON.SYSEXE] 


ACC.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ACLEDT.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
AGENSFEEDBACK.EXE;1 

[1,4] (RWED, RWED, RWED, RE) 
ANALAUDIT.EXE;1 {1,4] (RWED, RWED, RWED, RE) 
ANALIMDMP .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ANALYZBAD.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ANALYZOBJ.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ANALYZRMS.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
AUDIT_SERVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
AUTHORIZE.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
BACKUP .EXE;1 {1,4] (RWED, RWED, RWED, RE) 
BADBLOCK.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
BOOTS58 .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
BOOTBLOCK.EXE;1 Ei A) (RWED, RWED, RWED, RE) 
CDASCONVERT.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
CDU.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
CHECKSUM.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
CIA. EXE;1 [1,4] (RWED, RWED, RWED, RE) 
CLUSTER_AUTHORIZE.DAT;1 

[1,4] (RWED, RWE, RWE, ) 
CONFIGURE .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
CONVERT .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
COPY.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
CREATE .EXE;1 {1,4] (RWED, RWED, RWED, RE) 
CREATEFDL.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
CSP .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
CVTNAFV5 .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DBLMSGMGR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DCL. EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DCLDEF .STB;1 [1,4] (RWED, RWED, RWED, RE) 
DDIFSVIEW.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSBOOKREADER. EXE; 1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSCALC.EXE;1 {[1,4] (RWED, RWED, RWED, RE) 
DECWSCALENDAR. EXE; 1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSCARDFILER.EXE;1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSCLOCK.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSFONTCOMPILER.EXE;1 

(1, 4] (RWED, RWED, RWED, RE) 
DECWSMAIL.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSMAIL_ CREATEDECTERM.EXE;1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSMAIL EDIT.COM;1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSNOTEPAD .EXE;1 (1,4] (RWED, RWED, RWED, RE) 
DECWSPAINT.EXE;1 {1,4] (RWED, RWED, RWED, RE) 
DECWSPUZZLE.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DECWS$SERVER_MAIN.EXE;1 

eS (RWED, RWED, RWED, RE) 
DECW$SERVER_MAIN GB.EXE;1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSSESSION.EXE;1 [1,4] (RWED, RWED, RWED, RE) 


DECWSSETSHODIS.EXE;1 
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{1,4] (RWED, RWED, RWED, RE) 
DECWSSTARTLOGIN.EXE;1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSTERMINAL. EXE; 1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSUILCOMPILER.EXE;1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSWINMGR. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
DELETE .EXE;1 {1,4] (RWED, RWED, RWED, RE) 
DIFF .EXE;1 {[1,4] (RWED, RWED, RWED, RE) 
DIRECTORY.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DISKQUOTA.EXE;1 {1,4] (RWED, RWED, RWED, RE) 
DISMOUNT.EXE;1 {1,4] (RWED, RWED, RWED, RE) 
DNSSADVER. EXE; 1 {1,4] (RWED, RWED, RWED, RE) 
DNSSANALYZE.EXE;1 (1, 4] (RWED, RWED, RWED, RE) 
DNSSSOLICIT.EXE;1 {1, 4] (RWED, RWED, RWED, RE) 
DSRINDEX.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DSRTOC.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DTR.COM;1 [1,4] (RWED, RWED, RWED, RE) 
DTRECV.EXE;1 [2,4] (RWED, RWED, RWED, RE) 
DTSEND.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DUMP .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
EDF .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
EDT. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
ERF .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ERFADPTR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ERE BRIEF .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ERFBUS .EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
ERFCNTRL.EXE;1 {[1,4] (RWED, RWED, RWED, RE) 
ERFCVAX.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ERFDISK.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ERFDISK2.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ERFMISC.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ERFMSCP .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ERFRLTIM. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
ERFSCSI.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ERFSUMM.EXE;1 {1,4] (RWED, RWED, RWED, RE) 
ERFTAPE.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ERFUVAX.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ERFVAX7XX. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
ERFVX8200.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ERFVX8600.EXE;1 {1,4} (RWED, RWED, RWED, RE) 
ERFVX87XX. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
ERFXRP .EXE; 1 {1,4] (RWED, RWED, RWED, RE) 
ERREMT.EXE; 1 [1,4] (RWED, RWED, RWED, RB) 
ERRSNAP .EXE;1 {1,4] (RWED, RWED, RWED, RE) 
EVL.COM;1 [1,4] (RWED, RWED, RWED, RE) 
EVL.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
EXCHANGESNETWORK. EXE; 1 

[1,4] (RWED, RWED, RWED, RE) 
EXCHANGE .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
F11AACP.EXE;1 [1,4] (RWED, RWED, RWED, RB) 
F11BXQP.EXE;1 {1,4] (RWED, RWED, RWED, RE) 
FAL.COM;1 (1, 4] (RWED, RWED, RWED, RE) 
FAL.EXE;1 {1,4] (RWED, RWED, RWED, RE) 
FILESERV.EXE;1 {1,4] (RWED, RWED, RWED, RE) 
HLD.COM;1 {1,4] (RWED, RWED, RWED, RE) 


HLD .EXB; 1 [1,4] (RWED, RWED, RWED, RE) 
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HSCPAD .EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
IMGDEF .STB;1 [1,4] (RWED, RWED, RWED, RE) 
INIT.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
INP SMB .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
INSTALL. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
JBCSYSQUE.DAT;1 [1,4] (RWED, RWED, RE, ) 
JOBCTL.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
LALOAD .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
LALOADER. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
LATCP . EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
LATSYM.EXE;1 [1,4] (RWED, RWED, RWED, RF) 
LIBRARIAN .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
LINK. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
LMF SLICENSE.LDB;1 [1,4] (RWED, RWED, RE, ) 
LMFSLURT.DAT;1 [1,4] (RWED, RWED, RWED, RE) 
LMF . EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
LOGINOUT. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
MACRO32.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
MAIL.COM;1 [1,4] (RWED, RWED, RWED, RE) 
MAIL.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
MAILEDIT.COM;1 [1,4] (RWED, RWED, RWED, RE) 
MAIL SERVER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
MESSAGE.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
MIRROR.COM;1 [1,4] (RWED, RWED, RWED, RE) 
MIRROR. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
MOM. COM; 1 [1,4] (RWED, RWED, RWED, RE) 
MOM. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
MONITOR. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
MSCP .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
MTAAACP .EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
NCP .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
NCS.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
NETACP .EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
NETDEF .STB;1 [1,4] (RWED, RWED, RWED, RE) 
NETSERVER. COM; 1 [1,4] (RWED, RWED, RWED, RE) 
NETSERVER. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
NICONFIG.COM;1 [1,4] (RWED, RWED, RWED, RE) 
NICONFIG.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
NML.COM;1 [1,4] (RWED, RWED, RWED, RE) 
NML.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
OPCCRASH.EXE;1 {1,4] (RWED, RWED, RWED, RE) 
OPCOM.EXE; 1 eee (RWED, RWED, RWED, RE) 
PATCH. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
PHONE .COM;1 [1,4] (RWED, RWED, RWED, RE) 
PHONE .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
PRTSMB.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
QUEMAN .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
RECLAIM.EXE;1 {1,4] (RWED, RWED, RWED, RE) 
RECOVER. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
REMACP .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
RENAME .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
REPLY. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
REQSYSDEF.STB;1 [1,4] (RWED, RWED, RWED, RE) 
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REQUEST .EXE;1 


RIGHTSLIST.DAT;1 


RMSDEF .STB; 1 


[1,4] 
[1,4] 
[1,4] 


RMSRECS$RU_RECOVER.EXE;1 


RTB.EXE; 1 

RTPAD .EXE;1 
RUNDET . EXE; 1 
RUNOFF .EXE; 1 
SCSDEF.STB;1 
SDA.EXE;1 
SDLNPARSE .EXE;1 
SEARCH .EXE; 1 
SET. EXE; 1 
SETAUDIT.EXE;1 
SETPO.EXE;1 
SETRIGHTS .EXE;1 
SETSHOACL.EXE;1 
SETWATCH. EXE; 1 
SHOW. EXE; 1 
SHUTDOWN .COM; 1 
SHWCLSTR.EXE;1 
SMGBLDTRM.EXE;1 
SMGMAPTRM. EXE; 1 
SMGTERMS.TXT;1 
SMISERVER. EXE; 1 
SMPUTIL.EXE;1 
SORTMBERGE . EXE; 1 
SRTTRN.EXE; 1 
STABACCOP .EXE; 1 
STABACKUP .EXE;1 
STACONFIG.EXE;1 
STANDCONF . EXE; 1 
STARTUP .COM; 1 
STASYSGEN.EXE; 1 
STOPREM.EXE;1 
SUBMIT. EXE; 1 
SUCCESS .COM;1 
SUMSLP .EXE;1 
SYS.MAP;1 
SYS.STB;1 
SYSBOOT.EXE; 1 


SYSBOOT_XDELTA.EXE;1 


[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
(1,4) 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
(1, 4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 
[1,4] 


[1,4] 


(RWED, RWED, RWED, RE) 
(RWED, RWED, R, R) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
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SYSDEF.STB;1 [1,4] (RWED, RWED, RWED, RE) 
SYSGEN.EXE;1 [1,4 (RWED, RWED, RWED, RE) 
SYSINIT.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
SYSMAN .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
SYSUAF.DAT [1,4] (RWE, RWE, RWE, ) 
SYSUAF . TEMPLATE; 1 [1,4] (RWED, RWED, RWED, RE) 
TECO32.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
TERMTABLE .EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
TERMTABLE.TXT;1 [1,4] (RWED, RWED, RWED, RE) 
TERTIARY _VMB.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
TFFSMASTER.DAT;1 [1,4] (RWED, RWED, RWED, RE) 
TFU.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
TPU.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
TYPE. EXE;1 [1,4] (RWED, RWED, RWED, RE) 
UNLOCK .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
VAXVMSSYS.PAR [1,4] (RWED, RWED, RE, RE) 
VERIFY .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
VMB.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
VMBUVAX1P . EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
VMOUNT . EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
VMSSCHECK_DECNET.COM;1 

[1,4] (RWED, RWED, RWED, RE) 
VMSSINSTALL_UPG DATA.COM;1 

[1,4] (RWED, RWED, RWED, RE) 
VMSSRES2CAP .COM;1 [1,4] (RWED, RWED, RWED, RE) 
VMSSRES2CAP .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
VMSHELP .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
VMSMAIL PROFILE.DATA;1 

[1,4] (RWE, RWE, , ) 
VMSPARAMS .DAT;1 [1,4] (RWED, RWED, RWED, RE) 
VPM.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
VUESMASTER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
WP .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
WRITEBOOT.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
XFLOADER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
Total of 226 files. 
Directory SYSSSYSROOT: [SYSCOMMON.SYSFONT] 
DECW.DIR;1 [1,4] (RWE, RWE, RE, RE) 
PS FONT METRICS.DIR;1 

[1,4] (RWE, RWE, RE, RE) 
VWS .DIR;1 [1,4] (RWE, RWE, RE, RE) 
Total of 3 files. 
Directory SYS$SYSROOT: [SYSCOMMON.SYSFONT.DECW] 
100DPI.DIR;1 [1,4] (RWE, RWE, RE, RE) 
75DPI.DIR;1 [1,4] (RWE, RWE, RE, RE) 
CURSOR16.DIR;1 [1,4] (RWE, RWE, RE, RE) 
CURSOR32.DIR;1 [1,4] (RWE, RWE, RE, RE) 
USER_100DPI.DIR;1 [1,4] (RWE, RWE, RE, RE) 
USER_75DPI.DIR;1 [1,4] (RWE, RWE, RE, RE) 
USER_CURSOR16.DIR;1 

[1,4] (RWE, RWE, RE, RE) 
USER_CURSOR32.DIR;1 

{1, 4] (RWE, RWE, RE, RE) 
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Total of 8 files. 


Directory SYSSSYSROOT: [SYSCOMMON. SYSFONT.DECW.100DPI] 


x*k*k Following is the list of font files in this directory. KKK 
*xx*x* Each file has a file type of DECWSFONT and a UIC protection **** 


*xx**xk* mask of (RWED, RWED, RWED, RE) 


AVANTGARDE_BOOK10_100DPI 
AVANTGARDE_BOOK14_100DPI 
AVANTGARDE_BOOK24_100DPI 
AVANTGARDE. BOOKOBLIQUE10_100DPI 
AVANTGARDE _BOOKOBLIQUE14_ 100DPI 
AVANTGARDE _BOOKOBLIQUE24 100DPI 
AVANTGARDE DEMI10 100DPI~ 
AVANTGARDE DEMI14_ 100DPI 
AVANTGARDE _DEMI24_100DPI 
AVANTGARDE_DEMIOBLIQUE10_100DPI 
AVANTGARDE _DEMIOBLIQUE14 100DPI 
AVANTGARDE _DEMIOBLIQUE24_100DPI 
COURIER10_100DPI 

COURIER14 100DPI 
COURIER24_100DPI 
COURIER_BOLD10_100DPI 
COURIER_BOLD14_100DPI 
COURIER_BOLD24 100DPI 
COURIER_BOLDOBLIQUE10_100DPI 
COURIER_BOLDOBLIQUE14 100DPI 
COURIER_BOLDOBLIQUE24 100DPI 
COURIER_OBLIQUE10_100DPI 
COURIER_OBLIQUE14 100DPI 
COURIER_OBLIQUE24 100DPI 
DECWSSESSION_100DPI 
HELVETICA10_100DPI 
HELVETICA14_100DPI 
HELVETICA24_100DPI 

HELVETICA _BOLD10_100DPI 
HELVETICA _BOLD14_100DPI 
HELVETICA BOLD24 100DPI 
HELVETICA _BOLDOBLIQUE10_100DPI 
HELVETICA_BOLDOBLIQUE14_100DPI 
HELVETICA_BOLDOBLIQUE24_100DPI 
HELVETICA _OBLIQUE10_100DPI 
HELVETICA _OBLIQUE14_100DPI 
HELVETICA _OBLIQUE24_ 100DPI 
INTERIM_DM_EXTENSION14_ 100DPI 
INTERIM_DM_SYMBOL14_100DPI 
LUBALINGRAPH_BOOK12_100DPI 
LUBALINGRAPH_BOOK18_100DPI 
LUBALINGRAPH_ BOOK8 100DPI 
LUBALINGRAPH_BOOKOBLIQUE12_100DPI 
LUBALINGRAPH_BOOKOBLIQUE18_100DPI 
LUBALINGRAPH_BOOKOBLIQUE8_100DPI 
LUBALINGRAPH_DEMI12_100DPI 
LUBALINGRAPH DEMI18_100DPI 
LUBALINGRAPH_ DEMI8_100DPI 





KKKK 


AVANTGARDE_BOOK12_100DPI 
AVANTGARDE _BOOK18 100DPI 
AVANTGARDE_BOOK8_100DPI 
AVANTGARDE _BOOKOBLIQUE12_100DPI 
AVANTGARDE BOOKOBLIQUE18 100DPI 
AVANTGARDE _BOOKOBLIQUE8_100DPI 
AVANTGARDE DEMI12_100DPI 
AVANTGARDE _DEMI18_100DPI 
AVANTGARDE _DEMI8_100DPI 
AVANTGARDE _DEMIOBLIQUE12_100DPI 
AVANTGARDE_DEMIOBLIQUE18_100DPI 
AVANTGARDE _DEMIOBLIQUE8_100DPI 
COURIER12_100DPI 

COURIER18_ 100DPI 
COURIER8_100DPI 
COURIER_BOLD12_100DPI 
COURIER_BOLD18_100DPI 

COURIER _BOLD8_100DPI 


- COURIER_BOLDOBLIQUE12_100DPI 


COURIER _BOLDOBLIQUE18 100DPI 
COURIER BOLDOBLIQUE8 100DPI 
COURIER _OBLIQUE12_100DPI 

COURIER _OBLIQUE18 100DPI 

COURIER _OBLIQUE8 100DPI 

FIXED _100DPI 

HELVETICA12 100DPI 

HELVETICA18 100DPI 

HELVETICA8 100DPI 

HELVETICA BOLD12_100DPI 
HELVETICA BOLD18 100DPI 

HELVETICA BOLD8_100DPI 

HELVETICA _BOLDOBLIQUE12_100DPI 
HELVETICA BOLDOBLIQUE18 100DPI 
HELVETICA _BOLDOBLIQUE8_ 100DPI 
HELVETICA _OBLIQUE12_100DPI 
HELVETICA OBLIQUE18 1l00DPI 
HELVETICA OBLIQUE8 100DPI 
INTERIM DM ITALIC14 100DPI 
LUBALINGRAPH BOOK10_100DPI 
LUBALINGRAPH BOOK14 100DPI 
LUBALINGRAPH_ BOOK24_100DPI 
LUBALINGRAPH BOOKOBLIQUE10_100DPI 
LUBALINGRAPH_BOOKOBLIQUE14_100DPI 
LUBALINGRAPH BOOKOBLIQUE24_100DPI 
LUBALINGRAPH DEMI10_100DPI 
LUBALINGRAPH DEMI14 100DPI 
LUBALINGRAPH DEMI24_ 100DPI 
LUBALINGRAPH DEMIOBLIQUE10_100DPI 
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LUBALINGRAPH DEMIOBLIQUE12_100DPI 
LUBALINGRAPH_ DEMIOBLIQUE18_ 100DPI 
LUBALINGRAPH DEMIOBLIQUE8 100DPI 
MENU12_100DPI 
NEWCENTURYSCHLBK BOLD12 100DPI 
NEWCENTURYSCHLBK_BOLD18 100DPI 
NEWCENTURYSCHLBK BOLD8 100DPI 
NEWCENTURYSCHLBK BOLDITALIC12_100DPI 
NEWCENTURYSCHLBK BOLDITALIC18 100DPI 
NEWCENTURYSCHLBK_BOLDITALIC8_100DPI 
NEWCENTURYSCHLBK_ITALIC12_ 100DPI 
NEWCENTURYSCHLBK ITALIC18_ 100DPI 
NEWCENTURYSCHLBK_ITALIC8 100DPI 
NEWCENTURYSCHLBK_ ROMAN12_ 100DPI 
NEWCENTURYSCHLBK_ROMAN18 100DPI 
NEWCENTURYSCHLBK_ROMAN8_100DPI 
SOUVENIR_DEMI12_100DPI 
SOUVENIR_DEMI18_100DPI 
SOUVENIR_DEMI8 100DPI 

SOUVENIR DEMIITALIC12 100DPI 
SOUVENIR_DEMIITALIC18 100DPI 
SOUVENIR_DEMIITALIC8 100DPI 
SOUVENIR_LIGHT12_100DPI 
SOUVENIR_LIGHT18_100DPI 
SOUVENIR_LIGHT8 100DPI 
SOUVENIR_LIGHTITALIC12_100DPI 
SOUVENIR_LIGHTITALIC18 100DPI 
SOUVENIR_LIGHTITALIC8 100DPI 
SYMBOL12_100DPI 

SYMBOL18_ 100DPI 

SYMBOL8_100DPI 

TERMINAL14 10OODPI 

TERMINAL28 100DPI 

TERMINAL BOLD14 100DPI 

TERMINAL _BOLD28_100DPI 
TERMINAL BOLD DBLWIDE14 100DPI 
TERMINAL BOLD DBLWIDE DECTECH14 100DPI 
TERMINAL BOLD DECTECH14 100DPI 
TERMINAL BOLD DECTECH28 100DPI 
TERMINAL BOLD NARROW14 100DPI 
TERMINAL BOLD NARROW28 100DPI 
TERMINAL BOLD NARROW DECTECH14 100DPI 
TERMINAL BOLD NARROW DECTECH28 100DPI 
TERMINAL BOLD WIDE14 100DPI 

TERMINAL BOLD _WIDE_DECTECH14 100DPI 
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LUBALINGRAPH DEMIOBLIQUE14 100DPI 
LUBALINGRAPH_DEMIOBLIQUE24 100DPI 
MENU10_100DPI 
NEWCENTURYSCHLBK BOLD10_100DPI 
NEWCENTURYSCHLBK BOLD14 100DPI 
NEWCENTURYSCHLBK BOLD24_ 100DPI 
NEWCENTURYSCHLBK_BOLDITALIC10_100DPI 
NEWCENTURYSCHLBK_BOLDITALIC14_100DPI 
NEWCENTURYSCHLBK BOLDITALIC24_100DPI 
NEWCENTURYSCHLBK_ ITALIC10_100DPI 
NEWCENTURYSCHLBK_ITALIC14_100DPI 
NEWCENTURYSCHLBK ITALIC24 100DPI 
NEWCENTURYSCHLBK_ROMAN10_100DPI 
NEWCENTURYSCHLBK_ROMAN14_100DPI 
NEWCENTURYSCHLBK_ROMAN24_100DPI 
SOUVENIR_DEMI10_100DPI 
SOUVENIR_DEMI14 100DPI 
SOUVENIR _DEMI24 100DPI 
SOUVENIR_DEMIITALIC10_100DPI 
SOUVENIR DEMIITALIC14 100DPI 
SOUVENIR _DEMIITALIC24 100DPI 
SOUVENIR_LIGHT10_100DPI 
SOUVENIR_LIGHT14_100DPI 
SOUVENIR _LIGHT24_100DPI 
SOUVENIR_LIGHTITALIC10_100DPI 
SOUVENIR _LIGHTITALIC14 100DPI 
SOUVENIR _LIGHTITALIC24_ 100DPI 
SYMBOL10_100DPI 
SYMBOL14 100DPI 
SYMBOL24_ 100DPI 
TERMINAL10_100DPI 
TERMINAL20_100DPI 
TERMINAL BOLD10_100DPI 
TERMINAL BOLD20_100DPI 
TERMINAL BOLD DBLWIDE10_100DPI 
TERMINAL BOLD DBLWIDE_DECTECH10_100DPI 
TERMINAL BOLD DECTECH10_100DPI 
TERMINAL BOLD DECTECH20_100DPI 
TERMINAL BOLD NARROW10_100DPI 
TERMINAL BOLD NARROW20_100DPI 
TERMINAL BOLD NARROW _DECTECH10_100DPI 
TERMINAL BOLD NARROW DECTECH20_100DPI 
TERMINAL BOLD WIDE10_100DPI 
TERMINAL BOLD WIDE DECTECH10_100DPI 
TERMINAL DBLWIDE10_100DPI 
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TERMINAL DBLWIDE14 100DPI 


TERMINAL DBLWIDE_ DECTECH14 100DPI 


TERMINAL DECTECH14 100DPI 
TERMINAL DECTECH28 100DPI 
TERMINAL NARROW14_100DPI 
TERMINAL NARROW28_100DPI1 
TERMINAL NARROW DECTECH14 100DPI 
TERMINAL NARROW DECTECH28_ 100DPI 
TERMINAL WIDE14 100DPI 
TERMINAL WIDE _DECTECH14 100DPI 
TIMES BOLD12_100DPI 

TIMES BOLD18 100DPI 

TIMES BOLD8 100DPI 

TIMES BOLDITALIC12_100DPI 

TIMES BOLDITALIC18_100DPI 

TIMES BOLDITALIC8_100DPI 

TIMES ITALIC12_100DPI 

TIMES ITALIC18 100DPI 

TIMES ITALIC8 100DPI 

TIMES ROMAN12_100DPI 

TIMES ROMAN18 100DPI 

TIMES ROMAN8_100DPI 


Total of 230 files. 


Directory SYS$SYSROOT: [SYSCOMMON. 


**k*k*k Following is the list of font files in this directory. 
*xkk*k Each file has a file type of DECWSFONT and a UIC protection 
xx*k*k mask of (RWED, RWED, RWED, RE) 


AVANTGARDE _BOOK10 
AVANTGARDE _BOOK14 
AVANTGARDE _BOOK24 
AVANTGARDE BOOKOBLIQUE10 
AVANTGARDE _BOOKOBLIQUE14 
AVANTGARDE _BOOKOBLIQUE24 
AVANTGARDE _DEMI10 
AVANTGARDE_DEMI14 
AVANTGARDE DEMI24 
AVANTGARDE_DEMIOBLIQUE10 
AVANTGARDE _DEMIOBLIQUE14 
AVANTGARDE _ DEMIOBLIQUE24 
COURIER10 

COURIER14 

COURIER24 

COURIER_BOLD10 
COURIER_BOLD14 
COURIER_BOLD24 
COURIER_BOLDOBLIQUE10 
COURIER_BOLDOBLIQUE14 
COURIER_BOLDOBLIQUE24 
COURIER_OBLIQUE10 
COURIER_OBLIQUE14 
COURIER_OBLIQUE24 
DECWSSESSION 
HELVETICA1O 

HELVETICA14 
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TERMINAL DBLWIDE_DECTECH10 100DPI 


TERMINAL DECTECH10_100DPI 
TERMINAL DECTECH20 100DPI 
TERMINAL NARROW10_100DPI 
TERMINAL NARROW20_100DPI 
TERMINAL NARROW DECTECH10_100DPI 
TERMINAL NARROW DECTECH20_100DPI 
TERMINAL WIDE10_100DPI 
TERMINAL WIDE DECTECH10_100DPI 
TIMES BOLD10_100DPI 

TIMES BOLD14 100DPI 

TIMES BOLD24 100DPI 

TIMES BOLDITALIC10_100DPI 
TIMES BOLDITALIC14 100DPI 
TIMES BOLDITALIC24 100DPI 
TIMES ITALIC10_100DPI 

TIMES ITALIC14 100DPI 

TIMES ITALIC24_ 100DPI 

TIMES ROMAN10 100DPI 

TIMES ROMAN14 100DPI 

TIMES ROMAN24 100DPI 
VARIABLE_100DPI 


SYSFONT.DECW.75DPTI] 


KKK 
KKK 
KKKK 


AVANTGARDE_BOOK12 
AVANTGARDE_BOOK18 
AVANTGARDE _BOOK8 
AVANTGARDE _BOOKOBLIQUE12 
AVANTGARDE _BOOKOBLIQUE18 
AVANTGARDE _BOOKOBLIQUE8 
AVANTGARDE _DEMI12 
AVANTGARDE_DEMI18 
AVANTGARDE _DEMI8 
AVANTGARDE_DEMIOBLIQUE12 
AVANTGARDE _DEMIOBLIQUE18 
AVANTGARDE_DEMIOBLIQUE8 
COURIER12 

COURIER18 

COURIERS 

COURIER_BOLD12 
COURIER_BOLD18 
COURIER_BOLD8 
COURIER_BOLDOBLIQUE12 
COURIER_BOLDOBLIQUE18 
COURIER_BOLDOBLIQUE8 
COURIER_OBLIQUE12 
COURIER_OBLIQUE18 
COURIER_OBLIQUE8 

FIXED 

HELVETICA12 

HELVETICA18 
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HELVETICA24 
HELVETICA_BOLD10 
HELVETICA _BOLD14 

HELVETICA _BOLD24 
HELVETICA_BOLDOBLIQUE10 
HELVETICA BOLDOBLIQUE14 
HELVETICA BOLDOBLIQUE24 
HELVETICA_OBLIQUE10 
HELVETICA _OBLIQUE14 
HELVETICA_OBLIQUE24 
INTERIM_DM_ EXTENSION14 
INTERIM DM SYMBOL14 
LUBALINGRAPH_BOOK12 
LUBALINGRAPH_ _BOOK18 
LUBALINGRAPH_ BOOK8 
LUBALINGRAPH BOOKOBLIQUE12 
LUBALINGRAPH_BOOKOBLIQUE18 
LUBALINGRAPH BOOKOBLIQUE8 
LUBALINGRAPH DEMI12 
LUBALINGRAPH DEMI18 
LUBALINGRAPH DEMI8 
LUBALINGRAPH DEMIOBLIQUE12 
LUBALINGRAPH DEMIOBLIQUE18 
LUBALINGRAPH DEMIOBLIQUE8 
MENU12 
NEWCENTURYSCHLBK_BOLD12 
NEWCENTURYSCHLBK_BOLD18 
NEWCENTURYSCHLBK_BOLD8 
NEWCENTURYSCHLBK_BOLDITALIC12 
NEWCENTURYSCHLBK BOLDITALIC18 
NEWCENTURYSCHLBK BOLDITALIC8 
NEWCENTURYSCHLBK ITALIC12 
NEWCENTURYSCHLBK ITALIC18 
NEWCENTURYSCHLBK ITALIC8 
NEWCENTURYSCHLBK_ROMAN12 
NEWCENTURYSCHLBK_ROMAN18 
NEWCENTURYSCHLBK_ROMAN8 
SOUVENIR_DEMI12 
SOUVENIR_DEMI18 
SOUVENIR_DEMI8 
SOUVENIR_DEMIITALIC12 
SOUVENIR _DEMIITALIC18 
SOUVENIR_DEMIITALIC8 
SOUVENIR _LIGHT12 

SOUVENIR _LIGHT18 


HELVETICA8 
HELVETICA_BOLD12 
HELVETICA_BOLD18 
HELVETICA_BOLD8 
HELVETICA_BOLDOBLIQUE12 
HELVETICA_BOLDOBLIQUE18 
HELVETICA_BOLDOBLIQUE8 
HELVETICA_OBLIQUE12 
HELVETICA_OBLIQUE18 
HELVETICA_OBLIQUE8 
INTERIM _DM ITALIC14 
LUBALINGRAPH_BOOK10 
LUBALINGRAPH_BOOK14 
LUBALINGRAPH_BOOK24 
LUBALINGRAPH_BOOKOBLIQUE10 
LUBALINGRAPH_BOOKOBLIQUE14 
LUBALINGRAPH_BOOKOBLIQUE24 
LUBALINGRAPH_DEMI10 
LUBALINGRAPH_DEMI14 
LUBALINGRAPH_DEMI24 
LUBALINGRAPH_DEMIOBLIQUE10 
LUBALINGRAPH_DEMIOBLIQUE14 
LUBALINGRAPH_DEMIOBLIQUE24 
MENU1O 
NEWCENTURYSCHLBK_BOLD10 
NEWCENTURYSCHLBK_BOLD14 
NEWCENTURYSCHLBK_BOLD24 
NEWCENTURYSCHLBK_BOLDITALIC10 
NEWCENTURYSCHLBK_BOLDITALIC14 
NEWCENTURYSCHLBK_BOLDITALIC24 
NEWCENTURYSCHLBK_ITALIC10 
NEWCENTURYSCHLBK_ITALIC14 
NEWCENTURYSCHLBK_ITALIC24 
NEWCENTURYSCHLBK_ROMAN10 
NEWCENTURYSCHLBK_ROMAN14 
NEWCENTURYSCHLBK_ROMAN24 
SOUVENIR_DEMI10 
SOUVENIR_DEMI14 
SOUVENIR_DEMI24 
SOUVENIR_DEMIITALIC10 
SOUVENIR_DEMIITALIC14 
SOUVENIR _DEMIITALIC24 
SOUVENIR_LIGHT10 
SOUVENIR_LIGHT14 
SOUVENIR_LIGHT24 
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SOUVENIR LIGHTS 
SOUVENIR_LIGHTITALIC12 
SOUVENIR_LIGHTITALIC18 
SOUVENIR LIGHTITALIC8 
SYMBOL12 

SYMBOL18 

SYMBOL8 

TERMINAL14 

TERMINAL28 

TERMINAL BOLD14 

TERMINAL BOLD28 
TERMINAL BOLD DBLWIDE14 
TERMINAL BOLD DBLWIDE_DECTECH14 
TERMINAL BOLD DECTECH14 
TERMINAL BOLD DECTECH28 
TERMINAL BOLD NARROW14 
TERMINAL BOLD _NARROW28 
TERMINAL BOLD NARROW DECTECH14 
TERMINAL BOLD NARROW DECTECH28 
TERMINAL BOLD WIDE14 
TERMINAL BOLD WIDE _DECTECH14 
TERMINAL DBLWIDE14 
TERMINAL DBLWIDE_DECTECH14 
TERMINAL DECTECH14 
TERMINAL DECTECH28 
TERMINAL NARROW14 
TERMINAL NARROW28 
TERMINAL NARROW DECTECH14 
TERMINAL NARROW DECTECH28 
TERMINAL WIDE14 

TERMINAL WIDE_DECTECH14 
TIMES BOLD12 

TIMES BOLD18 

TIMES BOLD8 

TIMES BOLDITALIC12 

TIMES BOLDITALIC18 

TIMES BOLDITALIC8 

TIMES ITALIC12 

TIMES ITALIC18 

TIMES ITALIC8 

TIMES ROMAN12 

TIMES ROMAN18 

TIMES ROMANS 


Total of 230 files. 


SOUVENIR _LIGHTITALIC10 
SOUVENIR_LIGHTITALIC14 
SOUVENIR _LIGHTITALIC24 
SYMBOL10 

SYMBOL14 

SYMBOL24 

TERMINAL10 

TERMINAL20 

TERMINAL _BOLD10 

TERMINAL BOLD20 
TERMINAL BOLD DBLWIDE10 
TERMINAL BOLD _DBLWIDE_DECTECH10 
TERMINAL BOLD _DECTECH10 
TERMINAL BOLD _DECTECH20 
TERMINAL BOLD _NARROW10 
TERMINAL BOLD NARROW20 
TERMINAL BOLD _NARROW_DECTECH10 
TERMINAL BOLD NARROW DECTECH20 
TERMINAL BOLD WIDE10 
TERMINAL BOLD WIDE DECTECH10 
TERMINAL DBLWIDE10 
TERMINAL DBLWIDE_DECTECH10 
TERMINAL DECTECH10 
TERMINAL DECTECH20 
TERMINAL NARROW10 

TERMINAL NARROW20 
TERMINAL NARROW _DECTECH10 
TERMINAL NARROW DECTECH20 
TERMINAL WIDE10 
TERMINAL WIDE DECTECH10 
TIMES_BOLD10 

TIMES BOLD14 

TIMES BOLD24 

TIMES BOLDITALIC10 

TIMES BOLDITALIC14 

TIMES BOLDITALIC24 

TIMES ITALIC10 

TIMES ITALIC14 

TIMES ITALIC24 

TIMES ROMAN1O 

TIMES ROMAN14 

TIMES ROMAN24 

VARIABLE 


Directory SYSSSYSROOT: [SYSCOMMON.SYSFONT.DECW.CURSOR16] 


CURSOR. DECWSFONT; 1 [1,4] 
DECWSCURSOR. DECWSFONT; 1 
[1,4] 


files. 


(RWED, RWED, RWED, RE) | 


(RWED, RWED, RWED, RE) 


Directory SYSS$SYSROOT: [SYSCOMMON.SYSFONT.DECW.CURSOR32] 


DECW$C32X32 . DECWSFONT; 1 
[1,4] 


Total of 1 file. 


(RWED, RWED, RWED, RE) 
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Directory SYS$SYSROOT: [SYSCOMMON.SYSFONT.PS_ FONT METRICS] 


SYSTEM.DIR;1 [1,4] 
USER.DIR;1 [1,4] 


Total of 2 files. 


Directory SYS$SYSROOT: [SYSCOMMON.SYSFONT.PS FONT _METRICS.SYSTEM] 


AVANTGARDE _ BOOK.AFM; 1 


(RWE, RWE, RE, RE) 
(RWE, RWE, RE, RE) 


[1,4] (RWED, RWED, RWED, RE) 
AVANTGARDE_BOOKOBLIQUE. AFM; 1 

[1,4] (RWED, RWED, RWED, RE) 
AVANTGARDE _BOOKOBLIQUE_ISOLATIN1.AFM;1 

[1,4] (RWED, RWED, RWED, RE) 
AVANTGARDE_BOOK_ISOLATIN1.AFM;1 

[1,4] (RWED, RWED, RWED, RE) 
AVANTGARDE _DEMI.AFM;1 

[1,4] (RWED, RWED, RWED, RE) 
AVANTGARDE_DEMIOBLIQUE.AFM;1 

[1,4] (RWED, RWED, RWED, RE) 
AVANTGARDE _DEMIOBLIQUE_ISOLATIN1.AFM;1 

(1, 4] (RWED, RWED, RWED, RE) 
AVANTGARDE _DEMI_ISOLATIN1.AFM;1 

. [1,4] (RWED, RWED, RWED, RE) 

COURIER. AFM; 1 {1,4] (RWED, RWED, RWED, RE) 
COURIER_BOLD.AFM;1 {1,4] (RWED, RWED, RWED, RE) 
COURIER_BOLDOBLIQUE .AFM;1 

[1,4] (RWED, RWED, RWED, RE) 
COURIER_BOLDOBLIQUE_ISOLATIN1.AFM;1 

[1,4] (RWED, RWED, RWED, RE) 
COURIER_BOLD_ISOLATIN1.AFM;1 

[1,4] (RWED, RWED, RWED, RE) 
COURIER_ISOLATIN1.AFM;1 

[1,4] (RWED, RWED, RWED, RE) 
COURIER_OBLIQUE.AFM;1 

[1,4] (RWED, RWED, RWED, RE) 
COURIER_OBLIQUE_ISOLATIN1.AFM;1 

[1,4] (RWED, RWED, RWED, RE) 
HELVETICA.AFM;1 {1,4] (RWED, RWED, RWED, RE) 
HELVETICA _BOLD.AFM;1 

[1,4] (RWED, RWED, RWED, RE) 
HELVETICA_BOLDOBLIQUE.AFM; 1 

{1,4] (RWED, RWED, RWED, RE) 
HELVETICA_BOLDOBLIQUE_ISOLATIN1.AFM;1 

[1,4] (RWED, RWED, RWED, RE) 
HELVETICA_BOLD_ISOLATIN1.AFM;1 

{1,4] (RWED, RWED, RWED, RE) 
HELVETICA_ISOLATIN1.AFM;1 

[1,4] (RWED, RWED, RWED, RE) 
HELVETICA_OBLIQUE.AFM;1 

(1, 4] (RWED, RWED, RWED, RE) 
HELVETICA _OBLIQUE_ISOLATIN1.AFM;1 

(1, 4] (RWED, RWED, RWED, RE) 
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LUBALINGRAPH_ BOOK.AFM;1 

LUBALINGRAPH_ BOOKOBLIQUE.AFM;1 
LUBALINGRAPH BOOKOBLIQUE_ISOLATIN1 .AFM;1 
LUBALINGRAPH BOOK _ISOLATIN1 .AFM;1 
LUBALINGRAPH DEMI.AFM; 1 
LUBALINGRAPH_DEMIOBLIQUE.AFM;1 
LUBALINGRAPH DEMIOBLIQUE_ISOLATIN1.AFM;1 
LUBALINGRAPH DEMI_ ISOLATIN1.AFM;1 
NEWCENTURYSCHLBK BOLD.AFM; 1 
NEWCENTURYSCHLBK BOLDITALIC.AFM;1 
NEWCENTURYSCHLBK BOLDITALIC_ISOLATIN1.AFM;1 
NEWCENTURYSCHLBK BOLD ISOLATIN1.AFM;1 
NEWCENTURYSCHLBK ITALIC.AFM;1 
NEWCENTURYSCHLBK ITALIC ISOLATIN1.AFM;1 
NEWCENTURYSCHLBK ROMAN. AFM; 1 


NEWCENTURYSCHLBK_ROMAN_ ISOLATIN1.AFM;1 


SOUVENIR _DEMI .AFM; 1 


SOUVENIR DEMIITALIC.AFM; 1 
SOUVENIR_DEMIITALIC_ISOLATIN1.AFM;1 
SOUVENIR _DEMI_ISOLATIN1.AFM;1 
SOUVENIR_LIGHT.AFM;1 

SOUVENIR _LIGHTITALIC.AFM;1 

SOUVENIR LIGHTITALIC ISOLATIN1 .AFM;1 


SOUVENIR_LIGHT ISOLATIN1 .AFM;1 


SYMBOL.AFM;1 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
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TIMES BOLD.AFM;1 [1,4] (RWED, RWED, RWED, RE) 
TIMES BOLDITALIC.AFM;1 

[1,4] (RWED, RWED, RWED, RE) 
TIMES BOLDITALIC_ISOLATIN1.AFM;1 

[1,4] (RWED, RWED, RWED, RE) 
TIMES BOLD _ISOLATIN1.AFM;1 

[1,4] (RWED, RWED, RWED, RE) 
TIMES ITALIC.AFM;1 [1,4] (RWED, RWED, RWED, RE) 
TIMES ITALIC _ISOLATIN1.AFM;1 

[1,4] (RWED, RWED, RWED, RE) 
TIMES ROMAN.AFM;1 [1,4] (RWED, RWED, RWED, RE) 
TIMES ROMAN _ISOLATIN1.AFM;1 

[1,4] (RWED, RWED, RWED, RE) 
Total of 57 files. 
Directory SYSSSYSROOT: [SYSCOMMON.SYSFONT.VWS] 
100DPI.DIR;1 [1,4] (RWE, RWE, RE, RE) 
75DPI.DIR;1 [1,4] (RWE, RWE, RE, RE) 
USER_100DPI.DIR;1 [1,4] (RWE, RWE, RE, RE) 
USER_75DPI.DIR;1 [1,4] (RWE, RWE, RE, RE) 
Total of 4 files. 
Directory SYSSSYSROOT: [SYSCOMMON.SYSHLP] 
ACLEDT.HLB;1 [1,4] (RWED, RWED, RWED, RE) 
ANALAUDITSHELP .HLB; 1 

[1,4] (RWED, RWED, RWED, RE) 
ANLRMSHLP .HLB; 1 [1,4] (RWED, RWED, RWED, RE) 
DBGSDWHELP .HLB; 2 [1,4] (RWED, RWED, RWED, RE) 
DBGSHELP . HLB; 2 [1,4] (RWED, RWED, RWED, RE) 
DDIFSVIEW.HLB;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSCALC.HLB;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSCALENDAR.HLB; 1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSCARDFILER.HLB;1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSCLOCK.HLB; 1 [1,4] (RWED, RWED, RWED, RE) 
DECWSHELPHELP .HLB; 1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSMAIL.HLB; 1 [1,4] (RWED, RWED, RWED, RE) 
DECWSNOTEPAD.HLB;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSPAINT.HLB;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSPRINTWGT.HLB; 1 

(1,4) (RWED, RWED, RWED, RE) 
DECWSPUZZLE.HLB;1 {1,4] (RWED, RWED, RWED, RE) 
DECWSSESSION.HLB;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSTERMINAL.HLB; 1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSVUE.HLB; 1 [1,4] (RWED, RWED, RWED, RE) 
DISKQUOTA.HLB; 1 [1,4] (RWED, RWED, RWED, RE) 
EDFHLP .HLB; 1 [1,4] (RWED, RWED, RWED, RE) 
EDTHELP .HLB; 2 [1,4] (RWED, RWED, RWED, RE) 
EDTVT100.DOC;1 [1,4] (RWED, RWED, RWED, RE) 
EDTVT52.DOC;1 [1,4] (RWED, RWED, RWED, RE) 
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EVESHELP .HLB; 1 [1,4] (RWED, RWED, RWED, RE) 
EVESKEYHELP .HLB; 1 [1,4] (RWED, RWED, RWED, RE) 
EXAMPLES .DIR;1 [1,4] (RWE, RWE, RE, RE) 

EXCHNGHLP . HLB; 2 (1, 4] (RWED, RWED, RWED, RE) 
HELPLIB.HLB; 2 34] (RWED, RWED, RWED, RE) 
INSTALHLP .HLB; 1 [1,4] (RWED, RWED, RWED, RE) 
LATCP .HLB; 1 {1,4] (RWED, RWED, RWED, RE) 
MAILHELP .HLB; 2 [1,4] (RWED, RWED, RWED, RE) 
MNRHELP .HLB; 1 T1743 (RWED, RWED, RWED, RE) 
NCPHELP .HLB; 2 [1,4] (RWED, RWED, RWED, RE) 
PATCHHELP .HLB;1 [1,4] (RWED, RWED, RWED, RE) 
PHONEHELP . HLB; 1 [1,4] (RWED, RWED, RWED, RE) 
SDA.HLB;1 [1,4] (RWED, RWED, RWED, RE) 
SHWCLHELP . HLB; 1 [1,4] (RWED, RWED, RWED, RE) 
SYSGEN.HLB; 1 [1,4] (RWED, RWED, RWED, RE) 
SYSMANHELP .HLB; 1 [1,4] (RWED, RWED, RWED, RE) 
TECO.HLB;1 [1,4] (RWED, RWED, RWED, RE) 
TFFSTFUHELP .HLB; 1 {1, 4] (RWED, RWED, RWED, RE) 
TPUHELP .HLB; 1 [1,4] (RWED, RWED, RWED, RE) 
UAFHELP .HLB; 1 [1,4] (RWED, RWED, RWED, RE) 
WP .HLB;1 [1,4] (RWED, RWED, RWED, RE) 


Total of 45 files. 
Directory SYSSSYSROOT: [SYSCOMMON.SYSHLP .EXAMPLES] 


ADDRIVER.MAR; 1 [1,4] (RWED, RWED, RWED, RE) 
ADDUSER.COM; 1 [1,4] (RWED, RWED, RWED, RE) 
BACKUSER. COM; 1 [1,4] (RWED, RWED, RWED, RE) 
CLU_MOUNT_DISK.COM;1 

[1,4] (RWED, RWED, RWED, RE) 
CONNECT .COM; 1 [1,4] (RWED, RWED, RWED, RE) 
DB_REQUESTER.C;1 [1,4] (RWED, RWED, RWED, RE) 
DB_REQUESTER.MAR;1 [1,4] (RWED, RWED, RWED, RE) 
DB_SERVER.C;1 [1,4] (RWED, RWED, RWED, RE) 
DB_SERVER.MAR;1 [1,4] (RWED, RWED, RWED, RE) 
DECW.DIR;1 [1,4] (RWE, RWE, RE, RE) 
DOD_ERAPAT.MAR; 1 [1,4] (RWED, RWED, RWED, RE) 
DRCOPY .PRM; 1 [1,4] (RWED, RWED, RWED, RE) 
DRCOPYBLD.COM; 1 [1,4] (RWED, RWED, RWED, RE) 
DRMAST.MAR; 1 [1,4] (RWED, RWED, RWED, RE) 
DRMASTER. FOR; 1 [1,4] (RWED, RWED, RWED, RE) 
DRSLAVE.FOR; 1 [1,4] (RWED, RWED, RWED, RE) 
DRSLV.MAR; 1 [1,4] (RWED, RWED, RWED, RE) 
DTE_DF03.MAR;1 [1,4] (RWED, RWED, RWED, RE) 
DTE_DF112.MAR;1 [1,4] (RWED, RWED, RWED, RE) 
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EVESADVANCED.TPU; 1 [1,4] (RWED, RWED, RWED, RE) 
EVESBUILD.TPU;1 [1,4] (RWED, RWED, RWED, RE) 
EVESCONSTANTS.TPU;1 

[1,4] (RWED, RWED, RWED, RE) 
EVESCONSTANTS.UIL;1 

[1,4] (RWED, RWED, RWED, RE) 
EVESCORE.TPU;1 [1,4] (RWED, RWED, RWED, RE) 
EVESDECWINDOWS.TPU;1 

[1,4] (RWED, RWED, RWED, RE) 
EVESEDIT.TPU;1 [1,4] (RWED, RWED, RWED, RE) 
EVESEDT.TPU;1 [1,4] (RWED, RWED, RWED, RE) 
EVESEXTEND.TPU;1 [1,4] (RWED, RWED, RWED, RE) 
EVESEXTRAS.TPU;1 [1,4] (RWED, RWED, RWED, RE) 
EVESFILE.TPU;1 [1,4] (RWED, RWED, RWED, RE) 
EVESFORMAT.TPU; 1 [1,4] (RWED, RWED, RWED, RE) 
EVESHELP. TPU;1 {1,4] (RWED, RWED, RWED, RE) 
EVESMASTER.FILE;1 [1,4] (RWED, RWED, RWED, RE) 
EVESMENUS.TPU;1 [1,4] (RWED, RWED, RWED, RE) 
EVESMOUSE.TPU;1 [1,4] (RWED, RWED, RWED, RE) 
EVESOPTIONS.TPU;1 [1,4] (RWED, RWED, RWED, RE) 
EVESSHOW. TPU;1 [1,4] (RWED, RWED, RWED, RE) 
EVESSYNONYMS.TPU;1 [1,4] (RWED, RWED, RWED, RE) 
EVESTERMINALS.TPU;1 

[1,4] (RWED, RWED, RWED, RE) 
EVESVERSION.DAT;1 [1,4] (RWED, RWED, RWED, RE) 
EVESWIDGETS .UIL;1 [1,4] (RWED, RWED, RWED, RE) 
EVESWILDCARD.TPU;1 [1,4] (RWED, RWED, RWED, RE) 
EVESWINDOWS .TPU; 1 [1,4] (RWED, RWED, RWED, RE) 
EVESWPS.TPU;1 [1,4] (RWED, RWED, RWED, RE) | 
GBLSECUFO.MAR;1 [1,4] (RWED, RWED, RWED, RE) 
LABCHNDEF .FOR;1 [1,4] (RWED, RWED, RWED, RE) 
LABIO.OPT;1 [1,4] (RWED, RWED, RWED, RE) 
LABIOACQ.FOR;1 [1,4] (RWED, RWED, RWED, RE) 
LABIOCIN.MAR;1 [1,4] (RWED, RWED, RWED, RE) 
LABIOCIN.OPT;1 [1,4] (RWED, RWED, RWED, RE) 
LABIOCOM.FOR;1 {1,4] (RWED, RWED, RWED, RE) 
LABIOCOMP .COM; 1 [1,4] (RWED, RWED, RWED, RE) 
LABIOCON.FOR;1 [1,4] (RWED, RWED, RWED, RE) 
LABIOLINK.COM;1 [1,4] (RWED, RWED, RWED, RE) 
LABIOPEAK.FOR;1 [1,4] (RWED, RWED, RWED, RE) 
LABIOSAMP .FOR;1 (1, 4] (RWED, RWED, RWED, RE) 
LABIOSEC.FOR;1 [1,4] (RWED, RWED, RWED, RE) 
LABIOSTAT.FOR;1 [1,4] (RWED, RWED, RWED, RE) 
LABIOSTRT.COM;1 [1,4] (RWED, RWED, RWED, RE) 
LABMBXDEF .FOR;1 [1,4] (RWED, RWED, RWED, RE) 
LBRDEMO.COM;1 [1,4] (RWED, RWED, RWED, RE) 
LBRDEMO.FOR;1 [1,4] (RWED, RWED, RWED, RE) 
LBRMAC .MAR;1 [1,4] (RWED, RWED, RWED, RE) 
LOGIN.COM; 1 [1,4] (RWED, RWED, RWED, RE) 
LPATEST.FOR;1 [1,4] (RWED, RWED, RWED, RE) 
LPMULT.B32;1 [1,4] (RWED, RWED, RWED, RE) 
MGRMENU.COM; 1 [1,4] (RWED, RWED, RWED, RE) 
MONITOR.COM;1 [1,4] (RWED, RWED, RWED, RE) 
MONSUM. COM; 1 (1, 4] (RWED, RWED, RWED, RE) 
MSCPMOUNT. COM; 1 [1,4] (RWED, RWED, RWED, RE) 
PEAK.FOR;1 [1,4] (RWED, RWED, RWED, RE) 
RECOVERY_UNIT_SERVICES_.ADA;1 

[1,4] (RWED, RWED, RWED, RE) 
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RESTUSER.COM; 1 [1,4] (RWED, RWED, RWED, RE) 
RUFEXAMPLE.ADA;1 [1,4] (RWED, RWED, RWED, RE) 
RUFEXAMPLE.B32;1 [1,4] (RWED, RWED, RWED, RE) 
RUFEXAMPLE.BAS;1 [1,4] (RWED, RWED, RWED, RE) 
RUFEXAMPLE.C;1 [1,4] (RWED, RWED, RWED, RE) 
RUFEXAMPLE.COB; 1 [1,4] (RWED, RWED, RWED, RE) 
RUFEXAMPLE.COM;1 [1,4] (RWED, RWED, RWED, RE) 
RUFEXAMPLE. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
RUFEXAMPLE.FOR;1 [1,4] (RWED, RWED, RWED, RE) 
RUFEXAMPLE.PAS;1 [1,4] (RWED, RWED, RWED, RE) 
SCRFT.MAR;1 [1,4] (RWED, RWED, RWED, RE) 
SUBMON . COM; 1 [1,4] (RWED, RWED, RWED, RE) 
SYSGTTSTR.MSG;1 [1,4] (RWED, RWED, RWED, RE) 
TDRIVER. MAR; 1 [1,4] (RWED, RWED, RWED, RE) 
TESTLABIO.FOR;1 [1,4] (RWED, RWED, RWED, RE) 
USSDISP .MAR;1 [1,4] (RWED, RWED, RWED, RE) 
USSLNK.COM; 1 [1,4] (RWED, RWED, RWED, RE) 
USSTEST.MAR;1 [1,4] (RWED, RWED, RWED, RE) 
USSTSTLNK.COM; 1 [1,4] (RWED, RWED, RWED, RE) 
XADRIVER.MAR; 1 [1,4] (RWED, RWED, RWED, RE) 
XALINK.MAR;1 [1,4] (RWED, RWED, RWED, RE) 
XAMESSAGE .MAR; 1 [1,4] (RWED, RWED, RWED, RE) 
XATEST.COM;1 [1,4] (RWED, RWED, RWED, RE) 
XATEST.FOR;1 [1,4] (RWED, RWED, RWED, RE) 
XIDRIVER.MAR; 1 [1,4] (RWED, RWED, RWED, RE) 


Total of 97 files. 


Directory SYSS$SYSROOT: [SYSCOMMON.SYSHLP .EXAMPLES .DECW] 


ALLOBJS.H;1 [1,4] (RWED, RWED, RWED, RE) 
BITMAP .C;1 [1,4] (RWED, RWED, RWED, RE) 
BITMAP .EXE;1 {1, 4] (RWED, RWED, RWED, RE) 
CLOCK.DDIF;1 [1,4] (RWED, RWED, RWED, RE) 
DECBURGER.ADA;1 [1,4] (RWED, RWED, RWED, RE) 
DECBURGER.C;1 [1,4] (RWED, RWED, RWED, RE) 
DECBURGER. COM; 1 [1,4] (RWED, RWED, RWED, RE) 
DECBURGER.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DECBURGER.UID;1 [1,4] (RWED, RWED, RWED, RE) 
DECBURGER.UIL;1 {1,4] (RWED, RWED, RWED, RE) 
DEMO _BUILD.COM;1 {1,4] (RWED, RWED, RWED, RE) 
DIALOG.C;1 {1, 4] (RWED, RWED, RWED, RE) 
DWTVMSPUSHTEST.B32;1 

[1,4] (RWED, RWED, RWED, RE) 
DWTVMSPUSHTEST .EXE; 1 . 

[1,4] (RWED, RWED, RWED, RE) 
ENCODEFONT.PS;1 [1,4] (RWED, RWED, RWED, RE) 
HELLOWORLD.ADA;1 (1, 4] (RWED, RWED, RWED, RE) 
HELLOWORLD.C;1 (1, 4] (RWED, RWED, RWED, RE) 
HELLOWORLD .EXE; 1 {1, 4] (RWED, RWED, RWED, RE) 
HELLOWORLD.UID;1 [1,4] (RWED, RWED, RWED, RE) 
HELLOWORLD.UIL;1 [1,4] (RWED, RWED, RWED, RE) 
ICO.C;1 [1,4] (RWED, RWED, RWED, RE) 
ICO.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ICOPAS.PAS;1 [1,4] (RWED, RWED, RWED, RE) 
OBJCUBE.H;1 [1,4] (RWED, RWED, RWED, RE) 
OBJICO.H;1 {1,4] (RWED, RWED, RWED, RE) 
OBJTETRA.H;1 [1,4] (RWED, RWED, RWED, RE) 
PLAID.C;1 [1,4] (RWED, RWED, RWED, RE) 
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PLAID.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
POLYINFO.H;1 [1,4] (RWED, RWED, RWED, RE) 
STRINGS .MAR; 1 [1,4] (RWED, RWED, RWED, RE) 
XLIBINTRO.ADA;1 [1,4] (RWED, RWED, RWED, RE) 
XLIBINTRO.C;1 [1,4] (RWED, RWED, RWED, RE) 
XLIBINTRO.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
XLIBINTRO.FOR; 1 [1,4] (RWED, RWED, RWED, RE) 
Total of 34 files. 
Directory SYS$SYSROOT: [SYSCOMMON.SYSLIB] 
ACLEDIT.TPU;1 [1,4] (RWED, RWED, RWED, RE) 
ACLEDT$SECTION. TPUSSECTION; 1 

[1,4] (RWED, RWED, RWED, RE) 
ACLEDTSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ADARTL.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
BASRTL.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
BASRTL2 . EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
CDASACCESS.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
CDASCDA_.ADA;1 [1,4] (RWED, RWED, RWED, RE) 
CDASDEF ..BAS;1 [1,4] (RWED, RWED, RWED, RE) 
CDASDEF .FOR;1 [1,4] (RWED, RWED, RWED, RE) 
CDASDEF.H;1 [1,4] (RWED, RWED, RWED, RE) 
CDASDEF .MAR; 1 [1,4] (RWED, RWED, RWED, RE) 
CDASDEF .PAS;1 [1,4] (RWED, RWED, RWED, RE) 
CDASDEF .PLI;1 [1,4] (RWED, RWED, RWED, RE) 
CDASDEF .R32;1 [1,4] (RWED, RWED, RWED, RE) 
CDASMSG.BAS;1 [1,4] (RWED, RWED, RWED, RE) 
CDASMSG.FOR;1 [1,4] (RWED, RWED, RWED, RE) 
CDASMSG.H;1 [1,4] (RWED, RWED, RWED, RE) 
CDASMSG.MAR;1 [1,4] (RWED, RWED, RWED, RE) 
CDASMSG.PAS;1 [1,4] (RWED, RWED, RWED, RE) 
CDASMSG.PLI;1 [1,4] (RWED, RWED, RWED, RE) 
CDASMSG.R32;1 [1,4] (RWED, RWED, RWED, RE) 
CDASWRITE_ANALYSIS.EXE;1 

[1,4] (RWED, RWED, RWED, RE) 
CDDSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
CLIMAC.REQ;1 [1,4] (RWED, RWED, RWED, RE) 
COBRTL.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
CONVSHR.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
CRFSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DBGSSISHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DBLRTL.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DCLTABLES . EXE; 2 [1,4] (RWED, RWED, RWED, RE) 
DCXSHR.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
DDIFSDDIF_.ADA;1 [1,4] (RWED, RWED, RWED, RE) 
DDIFS$DEF .BAS;1 [1,4] (RWED, RWED, RWED, RE) 
DDIFSDEF .FOR;1 [1,4] (RWED, RWED, RWED, RE) 
DDIFSDEF.H;1 [1,4] (RWED, RWED, RWED, RE) 
DDIFS$DEF .MAR; 1 [1,4] (RWED, RWED, RWED, RE) 
DDIFSDEF .PAS;1 [1,4] (RWED, RWED, RWED, RE) 
DDIFSDEF.PLI;1 (1,4] (RWED, RWED, RWED, RE) 
DDIFSDEF .R32;1 [1,4] (RWED, RWED, RWED, RE) 
DDIFS$READ_TEXT.EXE;1 

[1,4] (RWED, RWED, RWED, RE) 
DDIF$STROKE_FONT1.DAT;1 

[1,4] (RWED, RWED, RWED, RE) 


DDIFSSTROKE_ FONT NEG3.DAT;1 
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[1,4] (RWED, RWED, RWED, RE) 

DDIF$STROKE_ FONT NEG9.DAT;1 

[1,4] (RWED, RWED, RWED, RE) 
DDIFSVIEW.UID;1 [1,4] (RWED, RWED, RWED, RE) 
DDIFSVIEWSHR. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
DDIFSWRITE_PS.EXE;1 

[1,4] (RWED, RWED, RWED, RE) 
DDIFSWRITE_TEXT.EXE;1 

[1,4] (RWED, RWED, RWED, RE) 
DEBUG.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DEBUGSHR.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
DEBUGUIL.UID;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSCALC.DAT;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSCALC.UID;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSCALENDAR. DAT; 1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSCARDFILER.DAT;1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSCARDFILER.UID;1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSCLOCK.DAT;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSCLOCK.UID;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSCURSOR.H;1 {1,4] (RWED, RWED, RWED, RE) 
DECWSDWTDEF . BAS; 1 [1,4] (RWED, RWED, RWED, RE) 
DECWSDWTDEF . FOR; 1 [1,4] (RWED, RWED, RWED, RE) 
DECWSDWTDEF .H;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSDWTDEF . MAR; 1 [1,4] (RWED, RWED, RWED, RE) 
DECWSDWTDEF .PAS;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSDWTDEF .PLI;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSDWTDEF .R32;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSDWTDEF .UIL;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSDWTLIBSHR.EXE;1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSDWTMSG.BAS;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSDWTMSG. FOR; 1 [1,4] (RWED, RWED, RWED, RE) 
DECWSDWTMSG.H;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSDWTMSG. MAR; 1 [1,4] (RWED, RWED, RWED, RE) 
DECWSDWTMSG.PAS;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSDWTMSG.PLI;1 {1,4] (RWED, RWED, RWED, RE) 
DECWSDWTMSG.R32;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSDWTWIDGETDEF .BAS;1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSDWTWIDGETDEF .FOR;1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSDWTWIDGETDEF .H;1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSDWTWIDGETDEF . MAR; 1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSDWTWIDGETDEF.PAS;1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSDWTWIDGETDEF .PLI;1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSDWTWIDGETDEF .R32;1 

[1,4] (RWED, RWED, RWED, RE) 
DECWSDWT_.ADA;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSLOGIN.DAT;1 [1,4] (RWED, RWED, RWED, RE) 
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DECWSLOGINOUT. EXE; 1 

[1,4] 
DECWSMAIL. DAT; 1 [1,4] 
DECWSMAILSHR.EXE;1 [1,4] 
DECWSNOTEPAD.DAT;1 [1,4] 
DECWSPAINT .DAT;1 [1,4] 
DECWSPRINTWGT.UID;1 


[1,4] 
DECWSPUZZLE.DAT; 1 [1,4] 
DECWSPUZZLE.UID;1 [1,4] 
DECWSSERVER_DDX_GA.EXE;1 
[1,4] 
DECWSSERVER_DDX_GB.EXE;1 
[1,4] 
DECWSSERVER_DDX_GC.EXE;1 
[1,4] 
DECWSSERVER_DIX.EXE;1 
{1,4] 
DECWSSESSION.DAT;1 [1,4] 
DECWSSM_BW.DAT;1 [1,4] 
DECWSSM_COLOR.DAT;1 
{1, 4] 
DECWSSM_GENERAL.DAT;1 
[1,4] 


DECWSSM_GRAY.DAT;1 [1,4] 
DECWSTERMINAL.DAT;1 


[1,4] 
DECWSTERMINAL.UID;1 

[1,4] 
DECWSTERMINALSHR. EXE; 1 

[1,4] 


DECWSTRANSPORT_COMMON.EXE; 1 


[1,4] 
DECWSTRANSPORT_DECNET.EXE; 1 

[1,4] 
DECW$TRANSPORT_LOCAL.EXE;1 

[1,4] 
DECWSUIL.ENV;1 [1,4] 
DECWSWINMGR.DAT;1 [1,4] 


DECWSXLIBDEF .BAS; 1 [1,4] 
DECWSXLIBDEF .FOR;1 [1,4] 
DECWSXLIBDEF.H;1 {1,4] 
DECWSXLIBDEF .MAR; 1 [1,4] 
DECWSXLIBDEF .PAS;1 [1,4] 
DECWSXLIBDEF.PLI;1 [1,4] 
DECWSXLIBDEF .R32;1 [1,4] 
DECWSXLIBMSG.BAS;1 {1,4] 


(RWED , RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 


(RWED , RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED , RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED , RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED , RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
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DECWSXLIBMSG.FOR;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSXLIBMSG.H;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSXLIBMSG.MAR;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSXLIBMSG.PAS;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSXLIBMSG.PLI;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSXLIBMSG.R32;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSXLIBSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSX_.ADA;1 [1,4] (RWED, RWED, RWED, RE) 
DELTA.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
DELTA.OBJ;1 [149 (RWED, RWED, RWED, RE) 
DISMNTSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DNSSCLIENT.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
DNSSRTL.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DNSSSHARE.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DNS.OLB; 1 [1,4] (RWED, RWED, RWED, RE) 
DNSDEF .BAS;1 [1,4] (RWED, RWED, RWED, RE) 
DNSDEF .FOR;1 [1,4] (RWED, RWED, RWED, RE) 
DNSDEF .H;1 eee a (RWED, RWED, RWED, RE) 
DNSDEF .MAR; 1 [1,4] (RWED, RWED, RWED, RE) 
DNSDEF.PAS;1 [1,4] (RWED, RWED, RWED, RE) 
DNSDEF.PLI;1 [1,4] (RWED, RWED, RWED, RE) 
DNSDEF .R32;1 (1, 4] (RWED, RWED, RWED, RE) 
DNSMSG.BAS;1 [1,4] (RWED, RWED, RWED, RE) 
DNSMSG.FOR;1 [1,4] (RWED, RWED, RWED, RE) 
DNSMSG.H; 1 [1,4] (RWED, RWED, RWED, RE) 
DNSMSG.MAR;1 [1,4] (RWED, RWED, RWED, RE) 
DNSMSG.PAS;1 [1,4] (RWED, RWED, RWED, RE) 
DNSMSG.PLI;1 [1,4] (RWED, RWED, RWED, RE) 
DNSMSG.R32;1 [1,4] (RWED, RWED, RWED, RE) 
DTE DF03.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DTE_DF112.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DTE DMCL.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DTKSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DYNSWITCH.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
EDTSHR.EXE;1 1,4] (RWED, RWED, RWED, RE) 
ENCRYPSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
EPCSFACILITY.TLB;1 [1,4] (RWED, RWED, RWED, RE) 
EPCSSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
EPMSSRVSHR. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
ERFCOMMON.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ERFCTLSHR.EXE;1 {1,4] (RWED, RWED, RWED, RE) 
ERFLIB.TLB;1 [1,4] (RWED, RWED, RWED, RE) 
ERFSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
ERFSHR2.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
EVESSECTION. TPUSSECTION; 1 

[1,4] (RWED, RWED, RWED, RE) 
EVESWIDGETS.UID;1 [1,4] (RWED, RWED, RWED, RE) 
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Exampie C—1 (Cont.) Protection Coaes ana Gwnersnip of Sysiem Fiies 
EVE .DAT;1 [1,4] (RWED, RWED, RWED, RE) 
FDLSHR.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
FORDEF .FOR;1 [1,4] (RWED, RWED, RWED, RE) 
FORIOSDEF . FOR; 1 [1,4] (RWED, RWED, RWED, RE) 
FORRTL.EXE;1 {1, 4] (RWED, RWED, RWED, RE) 
FORRTL2.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
IMAGELIB.OLB; 1 [1,4] (RWED, RWED, RWED, RE) 
IMGDMP .EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
LBRSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
LIB.MLB; 2 [1,4] (RWED, RWED, RWED, RE) 
LIB.REQ;1 [1,4] (RWED, RWED, RWED, RE) 
LIBDEF .FOR;1 [1,4] (RWED, RWED, RWED, RE) 
LIBRTL.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
LIBRTL2.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
MAILSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
MAILSHRP .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
MOUNTSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
MTHDEF .FOR;1 [1,4] (RWED, RWED, RWED, RE) 
MTHRTL.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
NCSSLIBRARY.NLB;1 [1,4] (RWED, RWED, RWED, RE) 
NCSSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
NISCS_LAA.EXE;1 {1,4] (RWED, RWED, RWED, RE) 
NISCS_LOAD.EXE;1 {1, 4] (RWED, RWED, RWED, RE) 
NMLSHR.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
PASRTL.EXE;1 [1,4] (RWED, RWED, RWED, RB) 
PGFALTMON.OBJ;1 ~ [1,4] (RWED, RWED, RWED, RE) 
PLIRTL.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
PPLRITL.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
RPGRTL.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
SCNRTL.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
SCRSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
SECURESHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
SECURESHRP . EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
SIGDEF .FOR;1 [1,4] (RWED, RWED, RWED, RE) 
SMBSRVSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
SMGSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
SMISOBJSHR.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
SMISSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
SORTSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
SPISHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
STARLET .MLB; 2 [1,4] (RWED, RWED, RWED, RE) 
STARLET .OLB; 2 [1,4] (RWED, RWED, RWED, RE) 
STARLET .REQ;1 [1,4] (RWED, RWED, RWED, RE) 
STARLETSD.TLB;1 {1,4] (RWED, RWED, RWED, RE) 
SUMSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
TECOSHR.EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
TFFSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
TPAMAC.REQ;1 [1,4] (RWED, RWED, RWED, RE) 
TPUSCCTSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
TPUSDEBUG.TPU;1 [1,4] (RWED, RWED, RWED, RE) 
TPUSDECWSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
TPU.DAT;1 {1, 4] (RWED, RWED, RWED, RE) 
TPUSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
TRACE .EXE;1 {1,4} (RWED, RWED, RWED, RE) 
UISSHR.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
UVMTHRTL.EXE;1 {1,4] (RWED, RWED, RWED, RE) 
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VAXCCURSE.OLB;1 [1,4] 
VAXCRTL.EXE;1 [1,4] 
VAXCRTL.OLB;1 [1,4] 
VAXCRTLG. EXE; 1 [1,4] 
VAXCRTLG.OLB;1 [1,4] 
VMSRTL.EXE;1 (1, 4] 
VUESDEFAULTS.DAT;1 [1,4] 
XFDEF .FOR;1 [1,4] 


Total of 226 files. 


Directory SYS$SYSROOT: [SYSCOMMON.SYSMGR] 


ALFMAINT.COM;1 [1,4] 
AUDIT _SERVER.DAT;1 {1,4] 
CLUSTER_CONFIG.COM;1 


[1,4] 
DBLSTRTUP .COM; 1 [1,4] 
DECWS$CHECK_PARAMS .COM; 1 

[1,4] 
DECWSDEVICE.COM;1 [1,4] 
DECWS$LOGICALS .COM; 1 

[1,4] 
DECWSPRIVATE_SERVER_SETUP.TEMPLATE; 1 

[1,4] 
DECWSRGB.COM; 1 [1,4] 
DECWSSTARTAPPS .COM; 1 

[1,4] 
DECWSSTARTLIBS .COM; 1 

[1,4] 
DECWS$STARTSERVER. COM; 1 

[1,4] 


DECWSSTARTSM.COM;1 [1,4] 
DECWSSTARTUP.COM;1 [1,4] 
DECWSSTARTVUE .COM; 1 

[1,4] 
DECWSSYLOGIN.COM;1 [1,4] 
DNSSCHANGE_DEF_FILE.COM;1 


[1,4] 
DNSS$CLIENT_STARTUP .COM;1 

[1,4] 
DNSSCLIENT_STOP.COM;1 

[1,4] 
EDTINI.EDT; 1 [1,4] 
EDTINI. TEMPLATE; 1 [1,4] 
LIBSDT_STARTUP .COM;1 

[1,4] 
LOADNET.COM; 1 [1,4] 
LOGIN.COM; 1 [1,4] 
LOGIN. TEMPLATE; 1 [1,4] 
LPA11STRT.COM;1 [1,4] 
LTLOAD.COM; 1 [1,4] 
MAKEROOT . COM; 1 [1,4] 
NETCONFIG.COM; 1 [1,4] 
RTTLOAD .COM; 1 [1,4] 
SECURITY_AUDIT.AUDIT$JOURNAL; 1 

1,4] 
SMISERVER.COM; 1 [1,4] 
STARTNET.COM; 1 [1,4] 





(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RE, ) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RE, ) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
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SYCONFIG.COM;1 [1,4] 
SYCONFIG. TEMPLATE; 1 
[1,4] 
SYLOGICALS .COM; 1 [1,4] 
SYLOGICALS . TEMPLATE; 1 
[1,4] 
SYLOGIN.COM;1 [1,4] 


SYLOGIN. TEMPLATE; 1 {1,4] 
SYPAGSWPFILES.COM;1 [1,4] 
SYPAGSWPFILES. TEMPLATE; 1 

[1,4] 
SYSECURITY.COM; 1 [1,4] 
SYSECURITY. TEMPLATE; 1 

[1,4] 
SYSHUTDWN.COM; 1 [1,4] 
SYSHUTDWN . TEMPLATE; 1 

[1,4] 
SYSTARTUP_V5.COM;1 [1,4] 
SYSTARTUP_V5.TEMPLATE; 1 


[1,4] 
TFFSSTARTUP .COM;1 [1,4] 
VMSIMAGES .DAT;1 [1,4] 
WELCOME .TEMPLATE; 1 [1,4] 
WELCOME .TXT;1 [1,4] 


Total of 51 files. 


Directory SYS$SYSROOT: [SYSCOMMON.SYSMSG] 


ADAMSG.EXE;1 [1,4] 
CLIUTLMSG. EXE; 1 [1,4] 
DBGTBKMSG . EXE; 1 {1,4] 
DBLRTLMSG. EXE; 1 [1,4] 


DDIFSVIEWMSG. EXE; 1 [1,4] 
DECWSDWTERRDB.DAT;1 


[1,4] 
DECWSDWIMSG. EXE; 1 [1,4] 
DECWS$MAIL MESSAGES .EXE;1 

(1, 4] 
DECWSTRANSPORTMSG. EXE; 1 

[1,4] 
DECWSXLIBERRDB.DAT;1 

[1,4] 
DECWSXLIBMSG.EXE;1 [1,4] 
DNSS$SMSG.EXE;1 [1,4] 
EPCSMSG.EXE;1 (1, 4] 
FILMNTMSG. EXE; 1 [1,4] 
LMF MESSAGE .EXE;1 [1,4] 
NETWRKMSG.EXE; 1 [1,4] 
PASMSG.EXE;1 [1,4] 
PLIMSG.EXE; 1 [1,4] 
PPLMSG.EXE; 1 [1,4] 
PRGDEVMSG.EXE; 1 [1,4] 
RPGMSG.EXE; 1 [1,4] 
SCNMSG.EXE; 1 [1,4] 
SHRIMGMSG.EXE; 1 [1,4] 
SYSMGTMSG.EXE; 1 [1,4] 
SYSMSG.EXE; 1 [1,4] 
TECOMSG .EXE; 1 [1,4] 


(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 


(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
(RWED, RWED, RWED, RE) 
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TPUMSG. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
VAXCMSG.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
VMSINSTAL_ LANGUAGE .COM; 1 

[1,4] (RWED, RWED, RWED, RE) 
VMSLICENSE_ LANGUAGE .COM; 1 

[1,4] (RWED, RWED, RWED, RE) 


Total of 30 files. 


Directory SYS$SYSROOT: [SYSCOMMON.SYSTEST] 


TCNTRL.CLD;1 [1,4] (RWED, RWED, RWED, RE) 
UETCDROO0.EXE; 1 {1,4} (RWED, RWED, RWED, RE) 
UETCLIGOO.COM;1 [1,4] (RWED, RWED, RWED, RE) 
UETCLIGOO.DAT;1 {1,4] (RWED, RWED, RWED, RE) 
VETCLIGOO.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
UETCOMS00.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
UETDISKO0.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
UETDMPFO00.EXE;1 {1,4] (RWED, RWED, RWED, RE) 
UETDNETOO.COM; 1 [1,4] (RWED, RWED, RWED, RE) 
UETDNETOO.DAT;1 [1,4] (RWED, RWED, RWED, RE) 
UETDR1W00.EXE;1 {1,4] (RWED, RWED, RWED, RE) 
UETDR7800.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
UETFORTO1.DAT;1 [1,4] (RWED, RWED, RWED, RE) 
UETFORTO1 .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
UETFORTO2.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
UETFORTO3.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
UETINITOO.EXE;1 (1, 4] (RWED, RWED, RWED, RE) 
UETINITO1.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
UETLOADOO .DAT;1 [1,4] (RWED, RWED, RWED, RE) 
UETLOADO2 .COM;1 {1,4] (RWED, RWED, RWED, RE) 
UETLOADO3.COM;1 [1, 4] (RWED, RWED, RWED, RE) 
UETLOADO4.COM;1 [1,4] (RWED, RWED, RWED, RE) 
UETLOADO5 .COM; 1 [1,4] (RWED, RWED, RWED, RE) 
UETLOAD06.COM;1 [1,4] (RWED, RWED, RWED, RE) 
UETLOADO7 .COM; 1 [1,4] (RWED, RWED, RWED, RE) 
UETLOADO8 .COM; 1 [1,4] (RWED, RWED, RWED, RE) 
UETLOADO9.COM;1 [1,4] (RWED, RWED, RWED, RE) 
UETLOAD10.COM;1 [1,4] (RWED, RWED, RWED, RE) 
UETLOAD11.COM;1 {1,4] (RWED, RWED, RWED, RE) 
UETLPAKOO .EXE;1 [1,4] (RWED, RWED, RWED, RE) 
UETMA7800.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
UETMEMY01 .EXE;1 {1,4] (RWED, RWED, RWED, RE) 
UETNETSOO.EXE;1 {1, 4] (RWED, RWED, RWED, RE) 
UETP .COM;1 [1,4] (RWED, RWED, RWED, RE) 
UETPHASOO.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
UETRSXFOR.EXE; 1 {1, 4] (RWED, RWED, RWED, RE) 
UETSUPDEV.DAT;1 [1,4] (RWED, RWED, RWED, RE) 
UETTAPEOO .COM;1 [1,4] (RWED, RWED, RWED, RE) 
UETTAPE00.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
UETTTYSOO.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
UETUNAS00 . EXE; 1 [1,4] (RWED, RWED, RWED, RE) 


Total of 41 files. 
Directory SYSSSYSROOT: [SYSCOMMON.SYSUPD] 
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Exampie C-1 (Cont) Protection Coaes ana Ownersnip ot System Fues 
AUTOGEN.COM;1 [1,4] (RWED, RWED, RWED, RE) 
BOOTUPD.COM;1 [1,4] (RWED, RWED, RWED, RE) 
CONSCOPY.COM;1 [1,4] (RWED, RWED, RWED, RE) 
CREATE IDX.EXE;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSCOMPILE ADA _UNITS.COM;1 

eae S (RWED, RWED, RWED, RE) 
DECWSKITBLD .DAT;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSKITBLD.IDX;1 [1,4] (RWED, RWED, RWED, RE) 
DECWSTAILOR. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
DECWSTAILOR_ON. TEMPLATE; 1 

[1,4] (RWED, RWED, RWED, RE) 
DXCOPY.COM;1 [1,4] (RWED, RWED, RWED, RE) 
LIBDECOMP .COM;1 (1, 4] (RWED, RWED, RWED, RE) 
LMFSCONFIG.COM;1 (1, 4] (RWED, RWED, RWED, RE) 
NETCONFIG_UPDATE.COM;1 

{1, 4] (RWED, RWED, RWED, RE) 
SETDEFBOO.COM;1 [1,4] (RWED, RWED, RWED, RE) 
SPKITBLD.COM;1 [1,4] (RWED, RWED, RWED, RE) 
STABACKIT-TABLE.DAT;1 

[1,4] (RWED, RWED, RWED, RE) 
STABACKIT.COM;1 [1,4] (RWED, RWED, RWED, RE) 
SWAPFILES.COM;1 [1,4] (RWED, RWED, RWED, RE) 
TAILOR _ON. TEMPLATE; 1 

[1,4] (RWED, RWED, RWED, RE) 
UPDATE_CONSOLE.COM; 1 

[1,4] (RWED, RWED, RWED, RE) 
VMBUVAX1.COM;1 [1,4] (RWED, RWED, RWED, RE) 
VMSSSYSTEM_ IMAGES .COM;1 

[1,4] (RWED, RWED, RWED, RE) 
VMSINSTAL.COM;1 [1,4] (RWED, RWED, RWED, RE) 
VMSKITBLD.COM;1 [1,4] (RWED, RWED, RWED, RE) 
VMSKITBLD.DAT;1 [1,4] (RWED, RWED, RWED, RE) 
VMSKITBLD.IDX;1 {1,4] (RWED, RWED, RWED, RE) 
VMSLICENSE.COM;1 [1,4] (RWED, RWED, RWED, RE) 
VMSTAILOR. EXE; 1 [1,4] (RWED, RWED, RWED, RE) 
VMSUPDATE.COM;1 [1,4] (RWED, RWED, RWED, RE) 
Total of 29 files. 
Directory SYSSSYSROOT: [SYSCOMMON. VUESLIBRARY] 
SYSTEM.DIR;1 [1,4] (RWE, RWE, RE, RE) 
USER.DIR;1 (3:49 


Total of 2 files. 


(RWE, RWE, RE, RE) 


Directory SYSS$SYSROOT: [SYSCOMMON.VUESLIBRARY. SYSTEM] 
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TPUSEDIT.COM;1 [1,4] (RWED, RWED, RWED, RE) 
TPUSEDIT_OPTIONS.UID;1 

[1,4] (RWED, RWED, RWED, RE) 
TPUSEDIT QUALIFIERS .EXE;1 

[1,4] (RWED, RWED, RWED, RE) 
VUE$BOOKREADER. COM; 1 

{1, 4] (RWED, RWED, RWED, RE) 
VUESCALCULATOR.COM; 1 

[1,4] (RWED, RWED, RWED, RE) 
VUESCALENDAR. COM; 1 {1, 4] (RWED, RWED, RWED, RE) 
VUESCARDE'ILER.COM; 1 

[1,4] (RWED, RWED, RWED, RE) 
VUESCLOCK.COM; 1 {1,4] (RWED, RWED, RWED, RE) 
VUESCOMPARE.COM; 1 {1,4] (RWED, RWED, RWED, RE) 
VUESCOMPILE.COM;1 [1,4] (RWED, RWED, RWED, RE) 
VUESCOPY.COM;1 {1,4] (RWED, RWED, RWED, RE) 
VUESCREATE_ DIRECTORY .COM; 1 

[1,4] (RWED, RWED, RWED, RE) 
VUESDCL_COMMAND .COM;1 

[1,4] (RWED, RWED, RWED, RE) 
VUESDDIF_VIEWER.COM;1 

[1,4] (RWED, RWED, RWED, RE) 
VUESDELETE.COM; 1 [1,4] (RWED, RWED, RWED, RE) 
VUESEDIT.COM; 1 [1,4] (RWED, RWED, RWED, RE) 
VUESHELP .COM; 1 {1,4] (RWED, RWED, RWED, RE) 
VUESICO.COM;1 [1,4] (RWED, RWED, RWED, RE) 
VUESLINK.COM; 1 [1,4] (RWED, RWED, RWED, RE) 
VUESMAIL.COM;1 [1,4] (RWED, RWED, RWED, RE) 
VUESNOTEPAD .COM; 1 [1,4] (RWED, RWED, RWED, RE) 
VUESPAINT.COM; 1 {1,4] (RWED, RWED, RWED, RE) 
VUESPLAID.COM;1 [1,4] (RWED, RWED, RWED, RE) 
VUESPRINT.COM; 1 [1,4] (RWED, RWED, RWED, RE) 
VUESPURGE.COM;1 [1,4] (RWED, RWED, RWED, RE) 
VUESPUZZLE.COM; 1 (1, 4] (RWED, RWED, RWED, RE) 
VUESRENAME .COM; 1 [1,4] (RWED, RWED, RWED, RE) 
VUESRUN.COM; 1 [1,4] (RWED, RWED, RWED, RE) 
VUES SEARCH.COM; 1 [1,4] (RWED, RWED, RWED, RE) 
VUES SHOW. COM; 1 [1,4] (RWED, RWED, RWED, RE) 
VUESSUBPROCESS_INIT.COM;1 

[1,4] (RWED, RWED, RWED, RE) 
VUESSYSTEM_ PROFILE. VUESDAT;1 

{1,4] (RWED, RWED, RWED, RE) 
VUESTYPE.COM;1 [1,4] (RWED, RWED, RWED, RE) 


Total of 33 files. 

Directory SYSSSYSROOT: [SYSERR] 

ERRLOG.SYS;1 [1,4] (RWED, RWED, RE, ) 
Total of 1 file. 

Directory SYS$SYSROOT: [SYSEXE] 
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AGENSADDHISTORY .DAT; 1 


[1,4] (RWED, RWED, RE, ) 
AUTOGEN .PAR;1 [1,4] (RWED, RWED, RE, ) 
LMFSSYSTEM.LDB; 1 [1,4] (RWED, RWED, RE, ) 
MODPARAMS . DAT; 2 fi; 2) (RWED, RWED, RE, ) 
NETCIRC.DAT;1 [1,4] (RWED, RWED, , ) 
NETCONF .DAT;1 [1,4] (RWED, RWED, , ) 
NETLINE.DAT;1 [1,4] (RWED, RWED, , ) 
NETLOGING.DAT;1 [1,4] (RWED, RWED, , ) 
NETNODE_LOCAL.DAT;1 

[1,4] (RWED, RWED, , ) 
NETOBJECT.DAT;1 [1,4] (RWED, RWED, , ) 
PAGEFILE.SYS;1 [1,4] (RWED, RWED, RE, ) 
PARAMS .DAT;1 [1,4] (RWED, RWED, RE, ) 
SETPARAMS .DAT; 1 (1, 4] (RWED, RWED, RE, ) 
STARTUP1.COM;1 [1,4] (RWED, RWED, RE, ) 
SWAPFILE.SYS;1 {i 24] (RWED, RWED, RE, ) 
SYSSINCARNATION.DAT;1 

[1,4] (RW, RW, R, R) 
SYSDUMP .DMP;1 [1,4] (RWED, RWED, , ) 
VAXVMSSYS.OLD;1 [1,4] (RWED, RWED, RE, ) 
VAXVMSSYS. PAR; 3 [1,4] (RWED, RWED, RE, ) 
VAXVMSSYS .PAR; 2 fi4] (RWED, RWED, RE, ) 


Total of 20 files. 

Directory SYSS$SYSROOT: [SYSHLP] 

EXAMPLES .DIR;1 {1, 4] (RWE, RWE, RE, RE) 
Total of 1 file. 

Directory SYS$SYSROOT: [SYSMGR] 


ACCOUNTNG.DAT;1 [1,4] (RWED, RWED, RE, ) 
OPERATOR. LOG; 1 {1, 4] (RWED, RWED, RE, ) 
VMSIMAGES .DAT; 1 [1,4] (RWED, RWED, , ) 


Total of 3 files. 
Grand total of 38 directories, 1654 files. 
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Many of the security features provided by VMS are directed toward the 
requirements for a class C2 system, as defined in the Department of 
Defense Trusted Computer System Evaluation Criteria, published by the 
Department of Defense Computer Security Center (CSC-STD-001-83). 


This appendix describes how some of the features of VMS relate to the 
C2 security model and notes some specific considerations for operating a 
VMS system within the C2 framework. Since the terminology used in this 
appendix is drawn from the evaluation criteria, you should be familiar 
with the government document before using this appendix. 


The Trusted Computing Base 


The Trusted Computing Base (TCB) provided by VMS encompasses much 
of the operating system. It includes the entire executive and file system, 
all other system components that execute in inner access modes (such 

as device drivers, RMS, and DCL), most system programs installed with 
privilege, and a variety of other utilities used by system managers to 
maintain data relevant to the TCB. 


The objects for which VMS provides full C2-style protection are files and 
directories that are accessible through normal file access techniques or 
through global sections. VMS also provides access controls of varying 
levels for other objects such as devices, logical name tables, and queues. 


Protecting the TCB 


The code and data that make up the VMS TCB reside in files and, in part, 
in the address space of the running operating system. Their integrity is 
protected by the use of file access controls and memory page protection. 
Memory page protection is set up by VMS as it executes and is normally 
not of concern to the system manager. The files containing the TCB 

are by default correctly protected when VMS is installed; however, the 
protection can be altered by sufficiently privileged users. Appendix C of 
this handbook describes the correct file protection of all VMS components. 


Certain privileges allow the holder to bypass normal file and memory 
access controls directly or indirectly and, therefore, must not be granted to 
persons other than the system manager, security officer, or other trusted 
persons. These privileges are described in detail in Appendix A of this 
handbook. Table 5-5 in this manual summarizes the privileges and 
categorizes them in terms of their sensitivity. 


Privileges in the FILES and ALL categories allow the holder to violate the 
integrity of the TCB. Privileges in the SYSTEM category allow the holder 
to interfere with normal system operation and cause denial of service; 
however, they do not allow the holder to actually violate object access 
controls. 
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Some privileges in the SYSTEM category also permit certain forms of 
deception that could ultimately result in violations of access controls. 
Privileges in the DEVOUR and GROUP categories permit the holder to 
consume resources without limit, thereby causing possible denial of service 
and interference with the operations of others in the same group. The 
GRPPEV privilege, in particular, permits the holder to violate normal 
access controls within that holder’s group. 


Individual Accountability 


The proper use of user names, UICs, and passwords ensures that 
individual accountability is enforced by VMS. The following practices 
and features, however, result in the loss of individual accountability and 
must not be used in a C2 environment: 


1 Do not assign the same UIC to more than one user. The UIC is used 
as the universal internal user identifier; therefore, unique UICs must 
be assigned to all users. 


2 Do not allow open accounts. Lack of a password makes an account 
available to all users aware of its identity. The system manager 
can prevent open accounts by never setting null passwords with 
AUTHORIZE and by ensuring that all accounts are set up with a 
nonzero minimum password length. 


3 Do not allow group accounts. Individual accountability is lost when 
more than one person shares an account. Each user must be given a 
unique account. 


4 Do not enable autologin. Autologin associates an account with a 
particular terminal instead of a particular person and, therefore, 
causes a loss of individual accountability. 


5 Do not initiate network proxy accounts for groups. In order to preserve 
individual accountability, each individual in a network must be given 
a unique network proxy account on each node to which that user has 
access. Assign the same user name and UIC on all applicable nodes. 
Then set up individual proxies among the corresponding accounts. 


Object Protection and Reuse 


File and directory protection is described extensively in Chapter 4. A 
series of mechanisms, described in Section 4.5, provides useful default 
protection for newly created objects. 


Reuse of system memory pages is protected by the memory management 
subsystem and cannot be defeated. Reuse of disk blocks is protected by 
the highwater marking and erase-on-delete features, which are described 
in Section 5.7. To conform to C2 criteria, all system disk volumes must 
have highwater marking enabled, which is the default. 


VMS considers magnetic tapes to be single user devices. Tape protection 
is available only at volume level. An entire volume can be assigned 
ownership and protection, but the individual files it contains cannot. 
Because of this policy, VMS provides no protection against reuse of 
tape. Tapes that are recycled to new users must be erased externally 
by operations personnel. 
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Frotection Of ine AuGii Traii 

The security audit trail is recorded in the security audit log file and on 
terminals enabled as security operators. The audit log file is normally 
protected against reading or modification by unauthorized users. 


To make sure evidence of system penetration cannot be fully erased by a 
malicious user, you can further protect the audit log file by adopting the 
following measures: 


1 Ina physically secure location, place a hardcopy terminal enabled as a 
security operator. 


2 Protect the audit log file with the following audit measures: 


a. By default, all use of the SET AUDIT command is audited. Review 
the system security audit log file regularly for all audit events. 


b. Place on the system security audit log file an ACL entry (ACE) 
that enables auditing of all attempts to modify or delete the audit 
log file: 


§ SET ACL SYSSMANAGER:SECURITY_AUDIT.AUDITSJOURNAL - 
_$ /ACL= (ALARM _JOURNAL=SECURITY, ACCESS=WRITE+DELETE+CONTROL+SUCCESS+FAILURE) 


Enter the following SET AUDIT command to enable ACL alarms: 
§ SET AUDIT/ALARM/ENABLE=ACL 


These audits ensure that any attempt to tamper with the audit log will 
be recorded. 


A complete description of the VMS security auditing facility is available in 
Chapter 6. 


Auditing Actions of a System Operator or Administrator 


Actions taken by trusted users of the system (operators, administrators, 
and security officers) can be audited by the enforced use of terminal 
session auditing as described in Section 6.6. Attempts to defeat the 
auditing can be detected by taking measures similar to those used to 
protect the audit log: 


1 Enable auditing of authorization modifications. 


2 Place ACL entries on the captive login command procedures and the 
directories containing them to detect modification of the procedures. 


Documentation 


The Guide to VMS System Security and any applicable reference 
documentation make up the Trusted Facility Manual for use by the system 
administrator. The first four chapters of this guide constitute the Security 
Features User’s Guide and should be made available to all system users. 
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Physical Security 


Physical and environmental security are critical to the secure operation 
of the system. Preventing theft of media and output is an obvious 
consideration. In addition, the console terminal must always be physically 
secured because it controls operation of the CPU and, consequently, 
operation of the system. 


Configuration Guidelines 


The security features described in this guide apply to most VAX 
configurations. They are supported by all VAX CPUs, including MicroVAX 
CPUs, and apply to all supported mass storage and communications 
devices. 


VAXcluster configurations also fully support the security features. A 
VAXcluster is considered a single security and management domain 
and normally operates with a shared authorization database. For more 
information, please refer to the VMS VAXcluster Manual. 


VMS does not meet the needs of the C2 requirements in configurations in 
which an MA780 shared memory subsystem is used as a shared memory 
among two or more independent processors. The communications objects 
in the shared memory (common event flag clusters, mailboxes, and global 
sections) do not support access control lists or security auditing. However, 
when a VAX-11/782 dual processor system uses the MA780 as the main 
memory, all security features are fully supported. 


The evaluation criteria do not address network operation. However, when 
connected to a DECnet network, VMS provides security commensurate 
with the security of the base operating system if the following restrictions 
are met: 


e All operating systems connected to the network are VMS systems 
or systems of equivalent security and are systems administered in a 
secure manner. 


¢ Default accounts are not provided for file and general task access. 
Limiting access to explicit access control strings and proxy access 
preserves individual accountability. 


e Communications lines are secured from wiretaps by use of link 
encryption devices or by physical security. 
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Alarm Messages 


This appendix describes alarm messages that result from auditing various 
system events. 





File and Global Section Alarms 


You can audit successful or unsuccessful access to a file or global section 
by specifying the FILE_ACCESS keyword with the /ENABLE qualifier 
of the SET AUDIT command. READ, WRITE, EXECUTE, DELETE, or 
CONTROL access modes can be audited. You can also audit successful 
access to a file or global section through the use of GRPPRV, READALL, 
SYSPRV, or BYPASS privilege. 


In addition to the information contained in all alarm messages, alarms 
that audit access to files and global sections contain the following: 


¢ Name of the file or global section accessed 
¢ Mode of access 
e Image used to access the file or global section 


e Privileges used to access the file or global section 


The following alarm messages are examples of the file and global section 
access alarms. 


ESEEEEEEEES OPCOM 7-DEC-1989 15:15:03.21 %%%%%%3%%S%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Attempted file access 

Event time: 7-DEC-1989 15:15:03.20 

PID: 20200283 

Username: WILSON 

Image name: LASSIESDMAO: [SYSO.SYSCOMMON. ] [SYSEXE] DIRECTORY .EXE 
Object name: _LASSIES$DMAO: [000000]000000.DIR;1 

Object type: file 

Access requested: READ 

Status: %SYSTEM-S-NORMAL, normal successful completion 


SEEEEEEESEESE OPCOM 7-DEC-1989 15:15:04.18  %%%%%3%%%%%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Attempted file access 

Event time: 7-DEC-1989 15:15:04.17 

PID: 20200283 

Username: WILSON 

Image name: LASSIESDMAO: [SYSO.SYSCOMMON. ] [SYSEXE] DIRECTORY .EXE 
Object name: _LASSIES$DMAO: [000000]000000.DIR;1 

Object type: file 

Access requested: READ 

Status: %SYSTEM-F-NOPRIV, no privilege for attempted operation 


%%% OPCOM 7-DEC-1989 15:15:29.46 %%%%%%%S%%%% 
Message from user AUDITSSERVER on LASSIE 
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Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Attempted global section access 

Event time: 7~DEC-1989 15:15:29.45 

PID: 00000112 

Username: — SYSTEM 

Image name: LASSIESDMAO: [SYSO.SYSCOMMON.] [SYSEXE]MAIL.EXE 

Global Section: SMGSTERMTABLE 

Object name: _LASSIESDMAO: [SYSO.SYSCOMMON. ] [SYSEXE] TERMTABLE .EXE;1 
Object type: global section 

Access requested: READ 

Status: %$SYSTEM-S-NORMAL, normal successful completion 


SSESSESESSEEE OPCOM 7-DEC-1989 15:15:32.22 %%%%%%%%%%% 
Message from user AUDITSSERVER on VENUS 
Security alarm (SECURITY) and security audit (SECURITY) on VENUS, system id: 19221 


Auditable event: Attempted global section access 

Event time: 7-DEC-1989 15:15:32.21 

PID: 000000A5 

Username: SYSTEM 

Image name: VENUSSDMAO: [SYSO.SYSCOMMON.] [SYSMGR] PRIV_USERS .EXE; 3 
Global Section: ACLEDT_002 

Object name: _VENUSSDMAO: [SYSO.SYSCOMMON.] [SYSEXE] ACLEDT.EXE;1 
Object type: global section 

Access requested: READ 

Status: SSYSTEM-F-NOPRIV, no privilege for attempted operation 


SSESSEEESESES  OPCOM 7-DEC-1989 21:01:49.95 %%%%%%%%%%% 
Message from user AUDITS$SERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Attempted file access 

Event time: 7-DEC~1989 21:01:49.94 

PID: 21200096 

Username: WILSON 

Image name: LASSIESDMAO: [SYSO.SYSCOMMON. ] [SYSEXE] DIRECTORY .EXE 
Object name: _LASSTIESDMAO: [000000]000000.DIR;1 

Object type: file 

Access requested: READ 

Status: SSYSTEM-S~NORMAL, normal successful completion 
Privileges used: SYSPRV 





Alarms Requested by an ACL 


The previous section describes alarms that audit access to all system files 
and global sections. You can audit successful or unsuccessful access to 
individual files by adding an ALARM_JOURNAL ACE to a file’s ACL and 
enabling ACL alarms with the SET AUDIT command. For example, the 
following ACE in a file’s ACL requests that an alarm occur whenever the 
file is successfully read: 


(ALARM_JOURNAL=SECURITY, ACCESS=SUCCESS+READ) 


The security alarm ACE has no effect uniess ACL alarms are enabled with 
the following command: 


$ SET AUDIT/ALARM/ENABLE= (ACL) 
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DATITMGD NDTOMNM ~.. AONIMDAT —.-3.. .-— La 
READ, WRITE, EXECU $4, Visi tiy, OF VUINL AVL TM0USS Call UG 


audited. In addition to the information contained in all alarm messages, 
ACL alarms contain the following: 


¢ Name of the file or global section accessed 
¢ Mode of access 
¢ Image used to access the file or global section 


e Privileges used to access the file or global section 


The following alarm messages are examples of alarms requested by an 
ACL. 


EEEESEESEEEE OPCOM 7-DEC-1989 12:19:38.56 %S33ESESSSS 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Attempted file access 

Event time: 7-DEC-1989 12:19:38.55 

PID: 21200096 

Username: WILSON 

Image name: LASSIESDMAO: [SYSO.SYSCOMMON. ] [SYSEXE] TYPE.EXE 
Object name: _LASSIESDMAO: [TIMMY] PRIVATE. LIS;1 

Object type: file 

Access requested: READ 

Status: %SYSTEM-S-NORMAL, normal successful completion 
Privileges used: SYSPRV 


$%% OPCOM 7-DEC-1989 12:20:14.61 %%%%%%%%%%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 





Auditable event: Attempted file access 

Event time: 7-DEC-1989 12:20:14.60 

PID: 21200096 

Username: WILSON 

Image name: LASSIESDMAO: [SYSO.SYSCOMMON. ] [SYSEXE] TYPE .EXE 

Object name: _LASSIESDMAO: [TIMMY] PRIVATE.LIS;1 

Object type: file 

Access requested: READ 

Status: SSYSTEM-F-NOPRIV, no privilege for attempted operation 
INSTALL Alarms 


You can audit the use of the Install Utility (to install an image or to 
remove an installed image) by specifying the INSTALL keyword with 

the /ENABLE qualifier of the SET AUDIT command. In addition to the 
information contained in all alarm messages, INSTALL alarms contain the 
following: 


¢ Type of INSTALL operation 

¢ Name of the image affected by the INSTALL operation 
e Flags set by INSTALL operation 

e Privileges used in the INSTALL operation 
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The following alarm messages are examples of alarms resulting from 


INSTALL operations. 


SESESEESEEE OPCOM 7-DEC-1989 12:37:49.69 %%%%%%%%%S% 
Message from user AUDITSSERVER on LASSIE 


Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 


Auditable event: Installed file addition 

Event time: 7-DEC-1989 12:37:49.68 

PID: 00000113 

Username: SYSTEM 

Object name: LASSIESDMAO: [SYSO.SYSCOMMON.] [SYSEXE] NCP .EXE;1 
Object type: file 

INSTALL flags: /OPEN/HEADER_RESIDENT/SHARED 


SESEEEESESE OPCOM 7-DEC-1989 12:38:02.11 %%%%%%%%%%% 
Message from user AUDITSSERVER on LASSIE 


Security alarm (SECURITY) and security audit (SECURITY) on Eneei ee system id: 


Auditable event: Installed file removal 

Event time: 7-DEC-1989 12:38:02.10 

PID: 00000113 

Username: SYSTEM 

Object name: LASSIESDMAO: [SYSO.SYSCOMMON. J] [SYSEXE]NCP.EXE;1 
Object type: file 

INSTALL flags: /OPEN/HEADER_RESIDENT/SHARED 


EEESESESEEES%  OPCOM 7—-DEC-1989 12:38:22.31 %&%%SSSSSBS% 
Message from user AUDITSSERVER on LASSIE 


Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 


Auditable event: Installed file addition 

Event time: 7-DEC-1989 12:38:22.25 

PID: 24E00A03 

Username: SMITH 

Object name: DUAS8: [SYS8.SYSCOMMON.] [SYSEXE] SDA.EXE;1 
Object type: file 

INSTALL flags: /PRIVILEGED 

Privileges used: CMKRNL 


ESEEESSESEE OPCOM 7-DEC-1989 12:39:16.12 %%%%%3%%%%% 
Message from user AUDITSSERVER on LASSIE 


Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 


Auditable event: Installed file removal 

Event time: 7-DEC-1989 12:39:16.10 

PID: 24E00A03 

Username: SMITH 

Object name: DUA8: [SYS8.SYSCOMMON. ] [SYSEXE] SDA. EXE;1 
Object type: file 

INSTALL flags: /PRIVILEGED 

Privileges used: CMKRNL 


Alarms Resulting from Modifications to the Rights Database 


19661 


19661 


19661 


19661 


You can audit any changes made to the rights database by specifying 
the AUTHORIZATION keyword with the /ENABLE qualifier of the SET 
AUDIT command. (The AUTHORIZATION class of security events is 


enabled by default.) 

Following are the types of changes that you can audit: 
¢ Creation of a new rights database 

e Addition of an identifier 
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¢ Removal of an identifi 
¢ Modification of an identifier 

¢ Granting of an identifier to a holder 
e Revoking an identifier from a holder 


¢ Modification of a holder 


In addition to the information contained in all alarm messages, this type 
of alarm contains the following: 


e Image used to modify the rights database 
e Change made to the rights database 


The following alarm messages are examples of alarms resulting from 
modification of the rights database. 


EEEEEEEEESE OPCOM 7-DEC-1989 12:40:54.69 %&%%%ESEEEE% 

Message from user AUDITSSERVER on LASSIE 

Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19661 
Auditable event: Rights database created 


Event time: 
PID: 
Username: 
Image name: 
Object name: 
Object type: 


7-DEC-1989 12:40:54.69 
24E00A03 
SMITH 
DUA8: [SYS8.] [SYSCOMMON. SYSEXE] AUTHORIZE .EXE 
SYSSSYSTEM:RIGHTSLIST.DAT;1 
file 


SEEEEEEESEES OPCOM 7-DEC-1989 12:41:01.05 %%%%%%3%%S%E% 

Message from user AUDITSSERVER on LASSIE 

Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19661 
Auditable event: Identifier added 


Event time: 
PID: 
Username: 
Image name: 


7-DEC-1989 12:41:01.04 
24E00A03 
SYSTEM 


DUA8: [SYS8.] [SYSCOMMON. SYSEXE] AUTHORIZE .EXE 


Identifier name: TIMMY 
Identifier value: %X80010000 Identifier attributes: none 


$%%%S%%%S%%%% ~ OPCOM 7~DEC-1989 12:41:19.52 %%%%%%%%%%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19661 


Event time: 
PID: 


Auditable event: Identifier removed 
7-DEC-1989 12:41:19.51 
24E00A03 
SYSTEM 


Username: 
Image name: 


DUAS8: [SYS8.] [SYSCOMMON. SYSEXE] AUTHORIZE .EXE 


Identifier name: TIMMY 
Identifier value: %X80010000 


EEEEEEEEEEE OPCOM 15-DEC-1989 12:27:17.44 %%%%%%%E%S%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19661 


Auditable event: Identifier modified 

Event time: 15-DEC-1989 12:27:17.43 

PID: 00000113 

Username: SYSTEM 

Image name: LASSIESDMAO: [SYSO.SYSCOMMON.] [SYSEXE] AUTHORIZE.EXE 
Identifier name: ROBINSON 

Identifier value: %$X80010014 New attributes: RESOURCE 
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SESSSSE%ESS% OPCOM 15-DEC-1989 12:27:17.44  %%%%%%%%3%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19661 


Auditable event: Identifier modified 

Event time: 15~DEC-1989 12:27:17.43 

PID: 20A00385 

Username: SMITH 

Image name: LASSIESDMAO: [SYSO.SYSCOMMON. ] [SYSEXE] AUTHORIZE.EXE 
Identifier name: DEMILO 

Identifier value: %X80010014 


New identifier value: %X8001007B 


SESESEEEEESE%SE OPCOM 15-DEC-1989 12:27:17.44  %%%%%3%%%3%%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19661 


Auditable event: Identifier modified 

Event time: 15-DEC-1989 12:27:17.43 

PID: 00000113 

Username: SMITH 

Image name: LASSIESDMAO: [SYSO.SYSCOMMON. ] [SYSEXE] AUTHORIZE. EXE 
Identifier name: STAFF 

Identifier value: SX800186A1 

New identifier name: MEETINGS 


EESSSSEESEE%  OPCOM 7-DEC-1989 12:37:49.69  %%%%%%%%%%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19661 


Auditable event: Identifier granted 

Event time: . 7-DEC-1989 12:37:49.69 

PID: 24E00A03 

Username: SYSTEM 

Image name: LASSIESDMAO: [SYSO.SYSCOMMON. ] [SYSEXE] AUTHORIZE. EXE 
Identifier name: PERSONNEL 

Identifier value: %$X80010000 Identifier attributes: none 

Holder name: PERKINS 

Holder owner: [214,202] 


EEESEEESEEES  OPCOM 7-DEC-1989 12:37:49.69 %%%%3%3%3%%3%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19661 


Auditable event: Identifier revoked 

Event time: 7-DEC-1989 12:37:49.69 

PID: 00000113 

Username: SYSTEM 

Image name: LASSIESDMAO: [SYSO.SYSCOMMON. ] [SYSEXE] AUTHORIZE .EXE 
Identifier name: PERSONNEL 

Identifier value: %X80010000 

Holder name: MANSON 

Holder owner: [214,210] 


ESEEEESEEEEE OPCOM 7-DEC-1989 12:37:49.69 %%%%%%%%%%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19661 


Auditable event: Identifier holder modified 

Event time: 7-DEC-1989 12:37:49.69 

PID: 00000113 

Username: SYSTEM 

Image name: LASSIESDMAO: [SYSO.SYSCOMMON. ] [SYSEXE] AUTHORIZE.EXE 
Identifier name: PAYROLL 

Identifier value: %X80010000 New attributes: RESOURCE 

Holder name: ARNOLD 

Holder owner: [220,133] 
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E.5 Alarms Resulting from Changes to SYSUAF or NETPROXY 
Specifying the AUTHORIZATION keyword with the /ENABLE qualifier of 
the SET AUDIT command enables auditing of changes made to the system 
UAF or network proxy authorization file in addition to auditing changes 
to the rights database. (The AUTHORIZATION class of security events is 
enabled by default.) 


Following are the types of changes that you can audit: 
e Adding a system UAF record 

¢ Deleting a system UAF record 

¢ Changing a system UAF record 

¢ Copying a system UAF record 

e Renaming a system UAF record 

e Adding network proxy access 

¢ Deleting network proxy access 

e Modifying network proxy access 

In addition to the information contained in all alarm messages, this type 
of alarm contains the following: 

¢ Record that was modified 


e Change that was made 


The following alarm messages are examples of alarms resulting from 
modification of the system or network UAF. 

SESESESESEESE OPCOM 18-DEC-1989 19:53:25.99 %%%%33%3%3S%SS% 

Message from user AUDITSSERVER on LASSIE 

Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: System UAF record additicn 

Event time: 18-DEC-1989 19:53:25.98 

PID: 20200B25 

Username: SYSTEM 

Image name: $1$DUS0: [SYSO.SYSCOMMON. ] [SYSEXE] AUTHORIZE.EXE 
Object name: SYSSCOMMON: [SYSEXE] SYSUAF .DAT; 2 

Object type: file 

User record added: COOPER 

Fields modified: FLAGS, PWOLIFETIME 


SESEESEESEESE OPCOM 18-DEC-1989 19:56:23.76 %%%%%%B%%S%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: System UAF record deletion 

Event time: 18-DEC-1989 19:56:23.75 

PID: 20200B25 

Username: SYSTEM 

Image name: $1$SDUS0: [SYSO.SYSCOMMON. ] [SYSEXE] AUTHORIZE.EXE 
Object name: SYSSCOMMON: [SYSEXE] SYSUAF .DAT;2 

Object type: file 

User record deleted: MELVILLE 


SSEEESSSSESE  OPCOM 18-DEC-1989 20:00:16.28  %%%%%%3%%S%S%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 
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Auditable event: System UAF record modification 

Event time: 18-DEC-1989 20:00:16.27 

PID: 20200B25 

Username: SYSTEM 

Image name: $1S$DUSO: [SYSO.SYSCOMMON. ] [SYSEXE] AUTHORIZE.EXE 
Object name: SYSSCOMMON: [SYSEXE] SYSUAF .DAT; 2 

Object type: file 

User record modified: GOWER 

Fields modified: PRIVILEGES 


EEESEEEEEESE OPCOM 18-DEC-1989 20:02:43.44  %%%%3%%%%S%% 
Message from user AUDITS$SERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: System UAF record copied 

Event time: 18-DEC-1989 20:02:43.43 

PID: 20200B25 

Username: SYSTEM 

Image name: $1SDUS0: [SYSO.SYSCOMMON. ] [SYSEXE] AUTHORIZE.EXE 
Object name: SYSSCOMMON: [SYSEXE] SYSUAF .DAT; 2 

Object type: file 

User record copied: JEFF 

Source user record: MUTT 

Fields modified: PASSWORD 


SEEESESEESSZ  OPCOM 18-DEC-1989 20:07:58.30 %%%%%%%%%%% 
Message from user AUDITS$SERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: System UAF record renamed 

Event time: 18-DEC-1989 20:07:58.29 

PID: 20200B25 

Username: SYSTEM 

Image name: $1SDUSO: [SYSO.SYSCOMMON.] [SYSEXE] AUTHORIZE.EXE 
Object name: SYSSCOMMON: [SYSEXE] SYSUAF.DAT; 2 

Object type: file 

User record copied: ALIAS 

New user record: SILAS 

Fields modified: PASSWORD 


EEEEESSEESE%E OPCOM 18-DEC-1989 20:14:05.39 %%%%%%%%%%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Network proxy record addition 

Event time: 18-DEC-1989 20:14:05.38 

PID: 20200B25 

Username: SYSTEM 

Image name: $1SDUSO: [SYSO.SYSCOMMON. ] [SYSEXE] AUTHORIZE.EXE 
Object name: SYSSCOMMON: [SYSEXE] NETPROXY.DAT;1 

Object type: file 

Remote nodename: VENUS 

Remote username: NETUSER 

Local accounts: GENACCESS 


SEEESEESEE%S OPCOM 18-DEC-1989 20:17:52.10 %%%%%%%%S%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Network proxy record modification 

Event time: 18-DEC-1989 20:17:52.09 

PID: 20200B25 

Username: GEORGES 

Image name:. $1SDUS0: [SYSO.SYSCOMMON.] [SYSEXE] AUTHORIZE .EXE 
Object name: SYSSCOMMON: [SYSEXE] NETPROXY.DAT;1 

Object type: file 

Remote nodename: VENUS 

Remote username: NETUSER 
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Default proxy account: GENACCESS 
Local accounts: GENACCESS2, GENACCESS3 


ESESEEEEEEESE OPCOM 18-DEC-1989 20:21:01.23 %%%%%%¥%¥44%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Network proxy record deletion 
Event time: 18-DEC-1989 20:21:01.22 

PID: 20200B25 

Username: SYSTEM 

Image name: $1SDUSO: [SYSO.SYSCOMMON. ] [SYSEXE] AUTHORIZE.EXE 
Object name: SYSSCOMMON: [SYSEXE] NETPROXY.DAT;1 
Object type: file 

Remote nodename: VENUS 

Remote username: NETUSER 

Default proxy account: GENACCESS 

Local accounts: GENACCESS2, GENACCESS3 





Alarms Resulting from Password Changes 


You can also audit changes to user passwords or the system password by 

specifying the AUTHORIZATION keyword with the /ENABLE qualifier of 
the SET AUDIT command. In addition to the information contained in all 
alarm messages, this type of alarm specifies which password was changed. 


The following alarm messages are examples of alarms resulting from 
password changes. 


$%3%E%E%E%E¥EEE% OPCOM 18-DEC-1989 20:28:22.49 %&S%%%EES%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: System UAF record modification 

Event time: 18-DEC-1989 20:28:22.48 

PID: 20200B25 

Username: SYSTEM 

Image name: $1SDUSO: [SYSO.SYSCOMMON. ] [SYSEXE] AUTHORIZE.EXE 
Object name: SYSSCOMMON: [SYSEXE] SYSUAF.DAT; 2 

Object type: file 

User record modified: DENNIS 

Fields modified: PASSWORD 


SEESEEESEEEES OPCOM 18-DEC-1989 20:27:22.86 %%%3%%%%%%EE% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: System UAF record modification 

Event time: 18-DEC-1989 20:27:22.85 

PID: 20200B25 

Username: SYSTEM 

Image name: $1$DUSO: [SYSO.SYSCOMMON. ] [SYSEXE] AUTHORIZE.EXE 
Object name: SYSSCOMMON: [SYSEXE] SYSUAF .DAT; 2 

Object type: file 

User record modified: <SYSTEM-PASSWORD> 

Fields modified: PASSWORD 


SESSESSESESS ~~ OPCOM 18-DEC-1989 11:42:11.36 %%%%%%%%%%% 
Message from user AUDITSSERVER on CANINE 
Security alarm (SECURITY) and security audit (SECURITY) on CANINE, system id: 19681 


Auditable event: System UAF record modification 

Event time: 18-DEC-1989 11:42:11.35 

PID: 0000004D 

Username: HOBBIT 

Image name: CANINESDUAO: [SYSO.SYSCOMMON. ] [SYSEXE] LOGINOUT. EXE 
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Object name: SYSSCOMMON: [SYSEXE] SYSUAF .DAT; 31 
Object type: file 

User record modified: HOBBIT 

Fields modified: PASSWORD 


S%EEEEEEEEE OPCOM 18-DEC-1989 11:42:42.31  %%%%%%%%%%% 
Message from user AUDITSSERVER on CANINE 
Security alarm (SECURITY) and security audit (SECURITY) on CANINE, system id: 19681 


Auditable event: System UAF record modification 

Event time: 18-DEC-1989 11:42:42.30 

PID: 00000038 

Username: HOBBIT 

Image name: CANINESDUAO: [SYSO.SYSCOMMON. ] [SYSEXE] SETP0O .EXE 
Object name: SYSSCOMMON: [SYSEXE] SYSUAF.DAT; 31 

Object type: file 

User record modified: HOBBIT 

Fields modified: PASSWORD 


Break-In Attempt Alarms 


You can audit break-in attempts by specifying the BREAKIN keyword with 
the /ENABLE qualifier of the SET AUDIT command. You can audit the 
DIALUP, LOCAL, REMOTE, NETWORK and DETACHED break-in types. 


In addition to the information contained in all alarm messages, this type 
of alarm contains the following: 


e Type of break-in attempt 

e Device used 

¢ Origin of attempt if the break-in type was REMOTE or NETWORK 
e Parent user name if the break-in type was DETACHED 


Passwords used in break-in attempts are not displayed on security 
operator terminals. The passwords are logged to the system security 
audit log file and can be displayed with the VMS Audit Analysis Utility. 


The following alarm messages are examples of the break-in attempt 
alarms. 
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SEEEESEEEEE OPCOM 7-DEC—1989 14:33:20.69 %%%%%E¥EESS% 
Message from user AUDITS$SERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Dialup interactive breakin detection 
Event time: 7-DEC~-1989 14:33:20.68 

PID: 00000052 

Username: SNIDELY 

Terminal name: _LTA13: (AV47C1/LC-2-10) 


$E%%EEEEEEEE OPCOM  7—-DEC-1989 14:32:58.79 %%%%%3%%%%%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Local interactive breakin detection 
Event time: 7-~DEC-1989 14:32:58.77 

PID: 00000051 

Username: SNIDELY 

Terminal name: _LTA13: (AV47C1/LC-2-10) 


EEEEEESEEESE OPCOM 7-DEC-1989 14:54:34.87 %%%%%%¥%3%E% 
Message from user AUDITS$SERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Remote interactive breakin detection 
Event time: 7-DEC-1989 14:54:34.83 

PID: 0000005D 

Username: FAGAN 

Remote nodename: NEPTUN Remote node id: 2211 
Remote username: PROBER 


SESESEEESES OPCOM 7-DEC-1989 14:55:28.51 %%%3%%%%%S%3% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Network breakin detection 

Event time: 7-DEC=-1989 14:55:28.50 

PID: OO00005E 

Username: DECNET 

Remote nodename: ORPHAN Remote node id: 6317 
Remote username: GUESSWHO 


$EEEEEEEEESE OPCOM 7-DEC-1989 16:14:59.72 %%%%%%%%3%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 





Auditable event: Detached process breakin detection 
Event time: 7-DEC-1989 16:14:59.60 

PID: 00000162 

Username: ARTFUL 

Parent username: SYSTEM 

Login Alarms 


You can audit successful logins by specifying the LOGIN keyword with 
the /ENABLE qualifier of the SET AUDIT command. You can audit 
BATCH, DIALUP, LOCAL, REMOTE, NETWORK, SUBPROCESS and 
DETACHED login types. 


In addition to the information contained in all alarm messages, this type 
of alarm contains the following: 


¢ Type of login 
e Device used 
¢ Origin of the login if it was REMOTE or NETWORK 
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e Parent PID if the login was SUBPROCESS 
e Parent user name if the login was DETACHED 


The following alarm messages are examples of successful login alarms. 


SESEESEEEEE OPCOM 18-DEC-1989 18:49:40.09 %%%%%%%%%%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Batch process login 
Event time: 18-DEC-1989 18:49:40.08 
PID: 20002001 

Username: LEWIS 


SEEEESESSEEESE OPCOM 18-DEC-1989 18:33:20.01 %%%%%%%%3%%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Dialup interactive login 
Event time: 18-DEC-1989 18:33:20.00 
PID: OOOO0E0S5 

Username: GRAHAM 

Terminal name: _LTA2: (MN23C1/LC-4-2) 


SSESEEEEESES OPCOM 18-DEC-1989 18:30:00.32 %%%%%%%%%%% 
Message from user AUDITS$SERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Local interactive login 
Event time: 18-DEC-1989 18:30:00.31 
PID: 20200BEF 

Username: NDREW 

Terminal name: _LTA4: (MN11C3/LC-1-3) 


SEEEEESSEEE OPCOM 18-DEC~1989 18:31:06.59 %%3333%3%%%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Remote interactive login 

Event time: 18-DEC-1989 18:31:06.58 

PID: 00000123 

Username: SYSTEM 

Terminal name: _RTAL: 

Remote nodename: MARS Remote node id: 5784 
Remote username: SYSTEM 


EESESSESEEE OPCOM 18-DEC-1989 18:20:41.01 %%%%%%%%S%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Network login 

Event time: 18-DEC-1989 18:20:41.00 

PID: 20200AF4 

Username: JOEUSER 

Remote nodename: AUSTIN Remote node id: 3034 
Remote username: JOEUSER 


EESESEEEEES OPCOM 18-DEC~-1989 18:03:27.90 %%%%%3%S%SE% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Subprocess login 

Event time: 18-DEC-1989 18:03:27.89 

PID: 20200115 Parent PID: 20200112 
Username: ADAM 


SEESSEEEES%S  OPCOM 18-DEC-1989 17:08:08.34  %%%%%%%%3%%% 
Message from user AUDITSSERVER on LASSIE 
' Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 
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Auditable event: Detachsd process login 

Event time: 18-DEC-1989 17:08:08.31 

PID: 00000093 Parent Username: ABRAHAM 
Username: ISSAC 





Login Failure Alarms 


You can audit login failures by specifying the LOGFAILURE keyword with 
the /ENABLE qualifier of the SET AUDIT command. You can audit the 
BATCH, DIALUP, LOCAL, REMOTE, NETWORK, SUBPROCESS and 
DETACHED login failure types. 


In addition to the information contained in all alarm messages, this type 
of alarm contains the following: 


e §6Type of login 

e Device used 

e Status detailing the reason for the failure 

e Origin of the login if it was REMOTE or NETWORK 
e Parent PID if the login was SUBPROCESS 

e Parent user name if the login was DETACHED 


The following alarm messages are examples of login failure alarms. 


SSEEEEEEEES OPCOM T7—DEC-1989 15:03:30.86 %&%ESEEEE¥SS 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Batch process login failure 

Event time: 7-DEC-1989 15:03:30.78 

PID: 00030060 

Username: RUBENS 

Status: %S$LOGIN-F-BADDAY, you are not authorized to login today 


SEESESEESEES OPCOM 7-DEC-1989 14:35:30.77 %%3%3%%S3%%S%S% 
Message from user AUDITSSERVER on TIGER 
Security alarm (SECURITY) and security audit (SECURITY) on TIGER, system id: 18772 


Auditable event: Dialup interactive login failure 
Event time: 7-DEC-1989 14:35:30.47 

PID: 00000057 

Username: LILY 

Status: $LOGIN-F-NOSUCHUSER, no such user 
Terminal name: _TTAL: 


EESEESEEEEESE OPCOM 7-DEC—-1989 14:23:22.00 %%%%%%%%%%% 
Message from user AUDITSSERVER on TIGER 
Security alarm (SECURITY) and security audit (SECURITY) on TIGER, system id: 18772 


Auditable event: Local interactive login failure 
Event time: 7-DEC-1989 14:23:22.00 

PID: 0000011C 

Username: TIMMY 

Terminal name: _LTA13: (AV47C1/LC-2-10) 

Status: SLOGIN-F-NOSUCHUSER, no such user 


SSESEEESESEEEE OPCOM 7-DEC-1989 12:40:50.40 %%%%%%%3%%%% 

Message from user AUDITS$SERVER on LASSIE 

Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 
Auditable event: Remote interactive login failure 

Event time: 7-DEC-1989 12:40:50.24 
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PID: 00000115 

Username: THOMPSON 

Terminal name: _RTAL: 

Source: 2.73 CANINE: :SYSTEM 

Remote nodename: TRNTO Remote node id: 12125 
Remote username: APROBER 

Status: %$LOGIN-F-NOSUCHUSER, no such user 


SESESEESEEESE OPCOM 7-DEC-1989 12:48:43.50 %%%%%%%%%%% 
Message from user AUDITS$SERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Network login failure 

Event time: 7-DEC-1989 12:48:43.49 

PID: 0000011D 

Username: DECNET 

Remote nodename: TIGER Remote node id: 3218 
Remote username: PROBER 

Status: %LOGIN-F-INVPWD, invalid password 


EEESEESEEEE OPCOM 7-—DEC-1989 17:07:54.60 %%%%%%%%%%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Subprocess login failure 

Event time: 7-DEC-1989 17:07:54.59 

PID: 00000195 Parent PID: 00000192 
Username: RANGER 

Status: %$LOGIN-F~OUTPUTERR, error opening primary 


output file SYSSOUTPUT 


EEEESEEEEEEE OPCOM 7-DEC-1989 12:49:30.69  %%%%%%%%E%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 13611 





Auditable event: Detached process login failure 

Event time: 7-DEC-1989 12:49:30.68 

PID: 0000011E5 Parent username: DOGGIE 
Username: PUPPY 

Status: %SYSTEM-F-NOLOGNAM, no logical name match 
Logout Alarms 


You can audit logouts by specifying the LOGOUT keyword with the 
/ENABLE qualifier of the SET AUDIT command. You can audit 
BATCH, DIALUP, LOCAL, REMOTE, NETWORK, SUBPROCESS and 
DETACHED logout types. _ 


In addition to the information contained in all alarm messages, this type 
of alarm contains the following: 


¢ Type of logout 

e Device used 

° Origin of the login if it was REMOTE or NETWORK 
¢ Parent PID if the login was SUBPROCESS 
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SEEEEEEEEES OPCOM 18-DEC-1989 18:49:44.65  %%%%%%%%E%%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, 


Auditable event: Batch process logout 
Event time: 18-DEC-1989 18:49:44.64 
PID: 20002001 

Username: LEWIS 


SEEESEEEEES OPCOM 18-DEC-1989 19:14:22.03 %%%%%S%SEE% 
Message from user AUDITS$SERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, 


Auditable event: Dialup interactive logout 
Event time: 18-DEC-1989 19:14:22.02 
PID: 20200001 

Username: DANCER 

Terminal name: _TTA1: 


SESEEEEEEEE OPCOM 18~-DEC-1989 18:44:15.57 %%%%%EEEES% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, 


Auditable event: Local interactive logout 
Event time: 18-DEC-1989 18:44:15.56 

PID: 20200AFF 

Username: MONET 

Terminal name: _LTA5: (VR21B2/LA-1-11) 


SEESEEEEEEESE OPCOM 18-DEC-1989 18:40:39.45 %&EEESEEEE% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, 


Auditable event: Remote interactive logout 

Event time: 18-DEC-1989 18:40:39.44 

PID: 00000247 

Username: INVENTORY 

Terminal name: _RTA4: 

Remote nodename: PLUTO Remote node id: 52119 
Remote username: JDANIELS 


SSESEEEEEES OPCOM 18-DEC-1989 18:33:45.92 %%%S%ESESEE% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, 


Auditable event: Network logout 

Event time: 18-DEC-1989 18:33:45.91 

PID: 20200AF5 

Username: DEMILO 

Remote nodename: BOSTON Remote node id: 21003 
Remote username: DEMILO 


SESEESEEEEE OPCOM 18-DEC-1989 12:49:59.49 %%%%%%%3%%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, 


Auditable event: Subprocess logout 

Event time: 18-DEC-1989 12:49:59.48 
PID: 00000120 

Username: TIMMY 


SEESESEESEEE OPCOM 18-DEC-1989 12:49:59.52 %4%%%%%%%%%% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, 


Auditable event: Detached process logout 
Event time: 18-DEC-1989 12:49:59.51 
PID: 00000093 

Username: DEMILO 
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E.11 Volume Mount and Dismount Alarms 


You can audit login failures by specifying the MOUNT keyword with 
the /ENABLE qualifier of the SET AUDIT command. In addition to the 
information contained in all alarm messages, this type of alarm contains 
the following: 


e Image used to mount the volume 

¢ Device used 

e Log file recording the operation 

e Volume name, UIC, and protection 


e Flags set during the operation 


The following alarm message is an example of a mount alarm. 


$%SSSSSSSS%S + OPCOM 18-DEC-1989 17:43:26.94  %%%%%%%%%%% 
Message from user AUDITSSERVER on CANINE 
Security alarm (SECURITY) and security audit (SECURITY) on CANINE, system id: 19681 


Auditable event: Volume mount 

Event time: 18-DEC-1989 17:43:26.04 

PID: 00000038 

Username: HOBBIT 

Image name: CANINESDUAO: [SYSO.SYSCOMMON. ] [SYSEXE] VMOUNT.EXE;1 
Object name: _CANINESMUAO: 

Object type: device 

Object owner: [DEVO, HOBBIT] 

Object protection: SYSTEM:RWEDC, OWNER:RWEDC, GROUP:RWEDC, WORLD: RWEDC 
Logical name: TAPESDBACK1 

Volume name: DBACK1 

Mount flags: /OVERRIDE=IDENT/MESSAGE 


The MOUNT keyword specified with the /ENABLE qualifier of the SET 
AUDIT command also enables auditing of dismount operations. In 
addition to the information contained in all alarm messages, this type 
of alarm contains the following: 


e Image used to dismount the volume 
e Device used 

¢ Log file recording the operation 

¢ Volume name 


e Flags set during the operation 


The following alarm message is an example of a dismount alarm. 


E-16 


E.12 


Aiarm Messages 
E.11 Volume Mount and Dismount Alarms 


SEEEEESEEEES OPCOM 18~DEC-1989 17:43:39.68 %%%%3%EEB3SSES 

Message from user AUDITSSERVER on CANINE 

Security alarm (SECURITY) and security audit (SECURITY) on CANINE, system id: 19681 
Auditable event: Volume dismount 


Event time: 18-DEC-1989 17:43:39.59 

PID: 00000038 

Username: HOBBIT 

Image name: CANINESDUAO: [SYSO.SYSCOMMON. ] [SYSEXE] DISMOUNT.EXE;1 
Object name: _CANINESMUAO: 

Object type: device 

Logical name: TAPESDBACK1 

Volume name: DBACK1 

Dismount flags: none 


Alarms Resulting from Execution of SET AUDIT Command 


All uses of the SET AUDIT command are automatically audited. You 
cannot disable auditing of the SET AUDIT command. 


The following alarm messages are examples of SET AUDIT alarms: 


SESEEEEESEE OPCOM 18-DEC-1989 10:11:19.42 %%3%%3%%SSS% 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Security audit alarms enabled 

Event time: 18-DEC-1989 10:11:19.40 

PID: 24E00A03 

Username: SMITH 

Auditing flags: LOGIN: (BATCH, DIALUP, LOCAL, REMOTE, NETWORK, SUBPROCESS, 
DETACHED), 
LOGOUT: (BATCH, DIALUP, LOCAL, REMOTE, NETWORK, SUBPROCESS, 
DETACHED) 


SEEEEEEESEE OPCOM 18-DEC-1989 10:12:58.84  %%%%%%3%%%S% 
Message from user AUDITS$SERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Security audit alarms disabled 
Event time: 18-DEC-1989 10:12:58.83 

PID: 24E00A03 

Username: SMITH 

Auditing flags: LOGIN: (DETACHED) 


LOGOUT: (DETACHED) 


%%E%ESEESEEE% + OPCOM 18-DEC-1989 21:44:18.41 %%%%%%S%EES 
Message from user AUDITSSERVER on LASSIE 
Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 


Auditable event: Audit server shutting down 
Event time: 18-DEC-1989 21:44:18.40 
PID: 20200C12 


SESSESESEEES OPCOM 18-DEC-1989 21:45:34.93 %%%%3%%%%%S% 

Message from user AUDITSSERVER on LASSIE 

Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 
Auditable event: Audit server starting up 

Event time: 18-DEC-1989 21:45:34.92 
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Access Control List: A list that defines the kinds of access to be granted or denied 
to users of an object. Access control lists can be created for objects such as files, 
devices, and mailboxes. Each access control list consists of one or more entries 
known as access control list entries. 


Access Control List Entry: An entry in an access control list. Access control list 
entries may specify identifiers and the access rights to be granted or denied the 
holders of the identifiers, default protection for directories, or security alarm 
details. Access control lists for each object can hold many entries, limited only by 
overall space and performance considerations. 


ACE: See Access Control List Entry 

ACL Editor: A VMS utility that helps users create and maintain access control lists. 
ACL: See Access Control List 

Alarm: See Security Alarm 


Alphanumeric UIC: A format of user identification code (UIC) that specifies the 
user’s group and member number in alphanumeric form rather than numeric 
form. 


Attribute: In the security context, an attribute is a field of information maintained 
in the rights database that identifies some characteristic accorded to all holders 
of the identifier. For example, if an identifier possesses the resource attribute, 
holders of that identifier are able to charge resources such as disk space usage to 
that identifier. | 


Auditing: The act of noting the occurrence of an event that has security 
implications. 


Authentication: The act of establishing the identity of users when they start to use 
the system. VMS (and most other commercial operating systems) use passwords 
as the primary authentication mechanism. 


Breach: A break in the system security that results in admittance of a person or 
program to an object. 


Break-In Attempt: An effort made by an unauthorized source to gain access to the 
system. Since the first system access is achieved through logging in, break-in 
attempts primarily refer to attempts to log in illegally. These attempts focus on 
supplying passwords for users known to have accounts on the system through 
informed guesses or other trial-and-error methods. 
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Captive Account: A type of VMS account that confines the user to the captive login 
command procedure. The use of CTRL/Y is disabled. If errors in the captive 
command procedure cause the procedure to terminate and attempt to return 
the user to the DCL command level, the process will be deleted. (This type of 
account is synonymous with a turnkey or tied account.) 


Decryption: The process that restores encoded information to its original unencoded 
form. 


Discretionary Controls: Security controls that are applied at the user’s option; that 
is, they are not required. Access control lists are typical of such optional security 
features. Discretionary controls are the oppposite of mandatory controls. 


Disk Scavenging: A term that refers to any method of obtaining information from 
a disk that the owner intended to discard. The information, although no longer 
accessible to the original owner by normal means, retains a sufficient amount 
of its original magnetic encoding that it can be retrieved and used by one of the 
scavenging methods. 


Encryption: A process of encoding information so that its content is no longer 
immediately obvious to anyone who obtains a copy of it. 


Erasure Pattern: A character string that can be used to overwrite magnetic media 
for the purpose of erasing the information that was previously stored in that 
area. 


Erase-on-allocate: A technique that applies an erasure pattern whenever a new 
area is allocated for a file’s extent. The new area is erased with the erasure 
pattern so that subsequent attempts to read the area can only yield the erasure 
pattern and not some valuable remaining data. This technique is used to 
discourage disk scavenging. 


Erase-on-delete: A technique that applies an erasure pattern whenever a file is 
deleted or purged. This technique is used to discourage disk scavenging. 


Evasive Action: A responsive behavior by VMS to discourage break-in attempts 
when they appear to be in progress. VMS has a set of criteria it uses to detect 
the fact that break-in attempts may be underway. Typically, once VMS becomes 
suspicious that an unauthorized user is attempting to log in, the evasive action 
consists of locking out all login attempts by the offender for a limited period of 
time. 


General Identifier: One of three possible types of identifiers that specify one or 
more groups of users. The general identifier is alphanumeric and typically is a 
convenient term that symbolizes the nature of the group of users. For example, 
typical general identifiers might be PAYROLL for all users allowed to run payroli 
applications or RESERVATIONS for operators at the reservations desk. 


Highwater Marking: A technique for discouraging disk scavenging. This technique 
tracks the furthest extent that the owner of a file has written into the 
file’s allocated area. It then prohibits any attempts at reading beyond the 
written area, on the premise that any information that exists beyond the 
currently written limit is information some user had intended to discard. VMS 
accomplishes the goals of highwater marking with its erase-on-allocate strategy. 
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Hoider: A user who possesses a particular identifier. The term holder is used 
in conjunction with the term identifier. Users are said to be the holders of 
identifiers if they possess the identifiers. The rights database is the place in 
the system where the associations of users and the identifiers they hold are 
permanently kept. However, each process also has a rights list that includes all 
the identifiers the process is authorized to hold. 


Identifier: A notation that defines a user or group of users. There are three types of 
identifiers: UIC identifiers, system-defined identifiers, and general identifiers. 


Locked Passwerd: A password that cannot be changed by the account’s owner. 
Only system managers or users with the SYSPRV privilege can change locked 
passwords. 


Login: The series of actions involved in authenticating a user to the system and 
creating a process that runs on the user’s behalf. 


Mandatory Controls: Security controls that are imposed by the system upon all 
users. There are no examples of mandatory controls within the VMS system. 
Mandatory controls are the opposite of discretionary controls. 


Nondiscretionary Controls: See Mandatory Controls 
Open Accounts: Accounts that do not require passwords. 


Passwords: Character strings that users provide at login time to validate their 
identity and as a form of proof of their authorization to access the account. 
There are system passwords and user passwords. User passwords include both 
primary and secondary passwords. 


Primary Password: A type of user password that is the first user password 
requested from the user. Systems may optionally require a secondary password, 
as well. This password must be the password that is associated with the user 
name that is supplied with it. 


Privileges: A means of protecting the use of certain system functions that can affect 
system resources and integrity. System managers grant privileges according to 
user’s needs and deny them to users as a means of restricting their access to the 
system. 


Proxy Login: A type of login that permits a user from a remote node to effectively 
log in to a local node as if the user owned an account on the local node. However, 
the user does not specify a password in the access control string. The remote 
user may own the account or share the account with other users. 


Restricted Account: A type of VMS account that limits the activities of the user. 
Typically, the user is restricted to using certain command procedures and 
commands. The user is not allowed to use the CTRL/Y key during the system 
or process login command procedure. Control may be turned over to the user 
following execution of the login command procedures. (This type of account is 
synonymous with a turnkey or tied account.) 


Rights Database: The collection of data the system maintains and uses to associate 
identifiers and the holders of the identifiers with their rights and attributes. 
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Rights List: The list associated with each process that includes all the identifiers 
the process holds. 


Secondary Password: A user password that may be required at login time 
immediately after the primary password has been correctly submitted. Primary 
and secondary passwords can be known by separate users to ensure that 
more than one user is present at the login. A less common use is to require 
a secondary password as a means of increasing the password length so that 
the total number of combinations of characters makes password guessing more 
time-consuming. 


Secure Terminal Server: VMS software designed to ensure that users can only log 
in to terminals that are already logged out. When the user presses the BREAK 
key on a terminal, the secure server (if enabled) responds by first disconnecting 
any logged-in process and then initiating a login. If no process is logged in at the 
terminal, the login can proceed immediately. 


Security Administrator: In the VMS context, the person or persons responsible for 
protecting the security of the computer system. This role is sometimes performed 
by the same person who functions as a system manager. It requires the same 
skills as the system manager, but includes additional privilege (the SECURITY 
privilege) as well as knowledge of the security features provided with the VMS 
operating system. 


Security Alarm: A message sent to operator terminals that are enabled as security 
operators. Security alarms are triggered by the occurrence of an event previously 
designated as worthy of the alarm because of its security implications. 


Security Manager: See Security Administrator 


Security Operator Terminal: A class of terminal that has been enabled to receive 
messages sent by OPCOM to “security operators”. These messages are security 
alarm messages. Normally such a terminal is a hardcopy terminal in a protected 
room. The output provides a log of security-related events and details that 
identify the source of the event. 


System-Defined Identifier: One of three classes of identifiers. System-defined 
identifiers are provided by the system to identify groups of users according to 
their usage of the system. For example, all users who access the system by 
dialing up receive the DIALUP identifier. 


System Password: A password required by a terminal before login can be initiated. 

Tied Account: See Captive Account 

Trojan riorse Program: A program that gains access to otherwise secured areas 
through its pretext of serving one purpose when its real intent is far more 
devious and potentially damaging. 

Turnkey Account: See Captive Account 


UIC: See User Identification Code 
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User iGeniification Code: A coded notation that represents a user of the system. 
Normally each user has a unique user identification code, although at a few 
sites some users may share the same UIC. In that case, there is no way for the 
system to distinguish one user from another. User identification codes include a 
designation of the user and the user’s group. 


User Password: A password that is associated with a user. This password must 
be correctly supplied when the user attempts to log in so that the user is 
authenticated for access to the system. The two types of user passwords are 
known as primary and secondary, also the sequence in which they are entered. 


Worm: A command procedure or executable image written and placed on the system 
for the sole purpose of seeking unauthorized access to files and accounts on 
the system. The “worm” seeks access to a user file through a flaw in the file 
protection. If successful, the worm modifies the file so that it carries a copy 
of the worm. Each time an unsuspecting user executes the code that contains 
the worm, the worm attempts to propagate itself into other poorly protected 
procedures or images, traveling along a path known as a worm-hole. The worm 
seeks to find its way into a procedure that will be run from a privileged account 
so that the worm can inflict damage to the system security. 
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management 5-8 
DELETE/ERASE commands» 4—40 
DELETE access* 4—5 

and directory files 4-8 

and disk file» 4-8 

and volume * 4—10 
DESNC security controllers 8-5 
DETACH privilege» A-3 
Device 

restricting access toe 5-29 
DIAGNOSE privilege» A-3 
Dialup 

backup synchronous and autoanswer« 8-6 

logins 3-2 

login failures * 3-16 

retries 

controlling» 5-22 

Dialup connection 

breaking properly » 3-22 
DIALUP identifiers 4-19, 5-4 
Directory 

access* 4-9 

deleting files 4~9 

ownership « 4-31 
DIRECTORY/OWNER command 4—32 
DIRECTORY/SECURITY command» 4—43 
Directory file default protections 4-33 
Disconnected job message * 3-5 
Disconnected process 

See Virtual terminal 
DISFORCE_PWD_CHANGE flag* 5-18 
Disk 

default protection « 4-34 

erasing» 4—40, 5-43 

file access* 4-8 

protections 4—2 
Disk quota 

as restriction for user * 5-30 

charging to identifiers » 4-29 

example * 5-13 
Disk scavenging * 4-39 

how to discourage * 5—42 
Disk space 

usage and chargings 4-29, 5-12 
Disk volume 

restrictions > 5-30 
DISMOUNT command 

alarms * E-16 
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DSE (data security erase) * 5-42, 5-43 
and erasure patterns 4-39 
tailoring» 5—43 
Dual passwords 
advantages and disadvantages * 5-16 
Dynamic attribute » 4—29 
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Editor 

See ACL editor 
Emergency account 

and privileges * 5-34 
Encryption 

of passwords 3-6 
Encryption algorithm * 3-6 
Environmental factors in security» 1-3 
Erasing disks * 4-40, 5-43 
Erasure patterns 4-39, 5-42 
Ethernet 

lack of protections 8—5 
Evasive action 

duration» 5-24 

invoked as counteraction for break-in * 5-23 
Event 

class* 6-4 

security * 6—1 
EXECUTE access* 4-5 

and directory file» 4-8 

and disk file> 4-8 

and volume * 4—10 
Expiration 

of account» 3-14 

of password + 3-10, 5-14 
/EXPIRATION qualifier * 5-31 
EXQUOTA privilege» A-3 
External node 

and default access rights * 8-6 
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Failures 
See Login failures 
Fiber optics 
application for network security 8-5 
File 
creating 
flowchart» 5-8 
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sensitive 
application of alarm* 4—42 
sharing 
considerations for a VAXcluster * 9-2 
sharing and exchanging 
in network environment* 8—18, 8-22 
transfers with MAIL+* 8-18 
write-only * 4-8 
File access 
See Access type 


See also UIC 
File browser * 3-13, 4—42, 7-3, 7-5 
File ownership rules * 4—32 
File protection violations 

auditing * 7-3 \ 
Files-11 structure * 4—9 
/FLAGS=CAPTIVE qualifier» 5-45 
/FLAGS=DISIMAGE qualifier» 5-49 
/FLAGS=DISMAIL qualifier» 5-21 
/FLAGS=DISNEWMAIL qualifier» 5-21 
/FLAGS=DISRECONNECT qualifier» 5-22 
/FLAGS=DISREPORT qualifier* 5-21 
/FLAGS=DISUSER qualifier» 5-20 
/FLAGS=DISWELCOME qualifier* 5-21 
/FLAGS=GENPWD qualifier» 5-17, 5-19 
/FLAGS=LOCKPWD qualifier» 5-19 
/FLAGS=PWD_EXPIRED qualifier * 5-18 
/FLAGS=RESTRICTED qualifiers 5-48 
Forgery of network information» 8—5 
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General identifier» 4-19, 4-20 

reasons for using* 4—28 
/GENERATE_PASSWORD qualifier 5—14 
GRANT/IDENTIFIER commands 5-6, 5-13 
Group 

design of* 5-2, 5-7 

impact on user privileges * 5-2 

overlapping user* 4—15 
Group name 

in UlC* 4-3 
Group number 

in UlC* 4-3 

uniqueness requirement for VAXcluster* 9-2 
GROUP privilege * A-3 
GROUP user category» 4—4 ( 
GRPNAM privilege « A-4 





GRPPRV orivilege + 4-6, A-4 

and user category» 4-4 

effect on ownership privilege * 4-31 
Guest accounts 


as limited-access accounts « 5—50 
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Hardcopy terminal 
logout considerations * 3—21 
Hexadecimal 
UIC identifier * 4—20 
Highwater marking» 4—40, 5-43 
and performance « 5—44 
Holder 
associating with identifier * 5-6 
displaying records * 5—7 
removal of 5-6 
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associating with holders » 5-6 

attributes * 4-29 

combined in one ACE 

example « 5-4 

design considerations » 5~3 

general» 4—19, 4-20 

removal of * 5-6 

reserved» 5-4 

system-defined > 4—19, 4-20 

types * 4~—19 

uniqueness requirement 

for VAXcluster * 9-2 

Identifier ACE * 4-22 

example of* 4-23 

specifying access in» 4-24 

specifying identifiers in* 4-22 

specifying options with» 4-23 
Image 

security ramifications * 5-33 
INITIALIZE/ERASE command + 5-43 
Install Utility (INSTALL) 

alarms « E-3 
INTERACTIVE identifier» 4-19, 5-4 
Interactive logins 3—1 
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Job controller 
affected by shift restrictions » 3-16 
enforcing work time restrictions > 5~30 
Job termination 
imposed by shift restrictions * 3-16 
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Kernel 
security * 2-2 
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LAN (local area network) 

lack of protections 8—5 
Last login messages * 3-5 

disabling * 5-21 

using» 4—40 
LAT 

See Terminal servers 
Levels of security 

defined* 1-2 
/LGICMD qualifier 

and captive accounts * 5—46 
LGI parameters * 5-22 
LGI_BRK_DISUSER parameter + 5-25 
LGI_BRK_LIM parameter + 5~23 
LGI_BRK_TERM parameter + 5-23 
LGI_BRK_TMO parameter + 5~23 
LGI_HID_TIM parameter» 5-24 
LGI_LRETRY_LIM parameter + 5-22 
LGILRETRY_TMO parameter + 5-22 
Lifetime account» 3-14 
Lifetime password * 3-10 
LINK/NOTRACE commands 5-34 
Listener device « 6-10 

example» 6-10 
Local area network 

See LAN 
LOCAL identifier» 4-19, 5-4 
LOCKPWD flag* 3-7 
Logging in 

See Login 
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Logging out 
after remote logins * 3-21 Mi 
from disconnected processes * 3-21 
security considerations * 3-20, 3-22 


Logins 3-1 Magnetic tape 
and default process protection» 4-34 EXECUTE and DELETE access» 4-10 
batch « 3-3 foreign access * 4—12 
class * 3-1 protection» 4—2, 4—12 
restrictions * 3-16 volume 
detached process * 3-3 protection codes 4-6 
dialup * 3-2 Mail file 
chances to supply password» 3-16 recommended protection for* 4—43 
controlling number of attempts * 5-22 Mail Utility (MAIL) 
disabled and system security » 3-20 
by break-in evasion + 3-16 notification message 
by shift restriction > 3-16 controlling » 5-21 
flags» 5-18 transferring text files * 8-18 
for expired accounts » 3-14 Marking 
interactive» 3—1 highwater * 4~40 
local» 3-2 Master file directory 
network: 3-3 See MFD 
noninteractive « 3-1 Matrix 
permitted time periods » 3-16 — access* 4-15, 4-17 
proxys 3-3 MAXSYSGROUP and SYSTEM category 4—4 
See Proxy login Media initialization 
remote» 3-2 restricting with ACLs * 5-40 
and system password» 5-15 Member name 
simplifying for user with ALF « 5-28 in UlC* 4-3 
subprocess * 3-4 Member number 
time outs 3-12 in UIC* 4-3 
type as system identifier» 4-19 Memory consumption 
Login alarms» E-11 paged system dynamic 
Login command procedure and ACLs* 5-4 
denying remote file access * 8-6 Message 
proper protection for» 5-41 announcement* 3-4 
Login failures * 3-6 disabling last logins 5-21 
alarms « E-13 disconnected job* 3-5 
and retries * 3-16 last logins 3-5 
causes of* 3-15 logins 3-4 
counting for break-in detection * 5~23 welcome * 3-5 
Login message » 3—4 MFD (master file directory)» 4-13 
controlling» 5-21 MODIFY/SYSTEM_PASSWORD command» 5-16 
suppression of * 3-6 MOUNT command 
Login program alarms * E-16 
authentication by secure servers 3-13 Mounting volumes 
LOGIO privilege» A—4 and security audit» 4—41, 6-11 
LOGOUT/HANGUP command + 3-22 MOUNT privilege» A-5 


Logout alarms * E-14 
LOGOUT commands 3-21 
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NETMBX privilege « A-5 
NETPROXY + 3-18 
NETPROXY.DAT 
and wildcards » 8~19 
normal protection * 5-20 
proxy authorization file 
automatic maintenance « 8—16 
Network 
conduit application > 8-5 
encryption» 8—5 
logins 3-3 
password guidelines * 8-6 
protected communications 
security problems 8-4 
usage restrictions 
in foreign countries * 8-7 
Network access control string * 3-13, 5-17 
Network accounts 
guidelines for establishment+ 8-5 
Network Control Program Utility (NCP) + 8-16 
Network default account 
and WORLD access* 8-4 
NETWORK identifier» 4—19, 5-4 
Network proxy authorization file (NETPROXY) 
See NETPROXY 
Network security * 8—1 
limitations * 8—1 
user considerations for* 3-17 
Node 
external 
and default access rights» 8-6 
Node database 
guidelines» 8-6 
Node name 
revealed at logout» 3-21 
Noninteractive login + 3-1 
Numeric UIC + 4—3 
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Object 
in security model» 2—1 
role in security» 2-3 
Object protection» 4—1, 4~2 
and system security * 4—1 
changing» 4—13 . 
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default ACL-based* 4-34 
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default UlC-based* 4-33 
establishing and changing * 4—13 
of magnetic tape volumes * 4—12 
Online debugging 
See Debugging 
OPCOM (Operator Communication Manager) * 6-6 
and security auditing» 6-5 
Open account* 3—7 
and captive accounts 5-45 
captive recommendation « 5—20 
Open files 
and ACL consumption of memory * 5—4 
Operator Communication Manager 


See OPCOM 
OPER privilege » A-5 
Ownership 
effects on protection checks * 4—28 
establishing and changing * 4-28, 4-32 
establishing directory * 4-31 
how assigned during file creation» 5-8 
management of defaults > 5-8, 5-11, 5-14 
Ownership privileges * 4-30 
OWNER user category * 4-4 
accessing magnetic tape * 4-6 
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Password 
See also System password 
automatic generation of* 3-9 
chances to supply during dialups * 3~16 
changing « 3-8, 3-10, 5-18 
frequency guidelines * 3-14 
choosings 3-8, 3-9, 3-12 
dual* 3-12, 5-14 
elimination for networks * 8-18 
encodings 2-3 
encryption 3-6 
expiration s 3-10 
how to pre-expire * 5-14 
settings 5-17 
forced change * 3-11, 5-18 
grabber* 3-13 
and logouts * 3-21 
secure server 
as antidote « 5-26 
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Password (cont'’d.) 
initial» 5-14 
keeping former * 3-11 
length, minimum « 5—19 
lifetime * 3-10 
locked* 3~—7 
advantage * 5-19 
for captive accounts * 5—45 
management+ 5-14, 5-20 
minimum length + 3-8, 3-11 
and automatic generation + 3-9 
network guidelines * 8-6 
news 3-8 
null 
as choice for captive account» 5-45 
primary * 3-12, 5-14 
retries * 3—16 
role in security * 2-3 
secondary * 3-12, 5-16 
sharing» 3-14, 8-18 
stealing programs * 3-13 
storings 3-6 
system 3-7 
user 
defined + 3-6 
uniqueness on each account+ 3-14 
using on multiple systems * 3-14 
Password generator 
obtaining initial password» 5—14 
when to require» 5-19 
Password protection» 3-13, 5—20 
avoiding detection» 3-9, 3-11, 5-24, 7-5 
dialup retries * 3-16 
/PASSWORD qualifier * 5-17 
Penetration 
as security problems 1-2 
Performance 
and ACL length» 5-4 
and automatic password generator + 5-19 
and highwater marking « 5-44 
PFNMAP privilege» A-6 
Physical security» 1-3 
of networks « 8-5 
PHY_IO privilege > A-6 
Ports, publicly accessible » 5—16 
/PRCLM qualifiers 5-48 
/PRIMEDAYS qualifier 
example * 5-30 
Privilege 
alle 5-33 
BYPASS « 4-6 
devours 5-32 
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files * 5-33 
for captive account» 5-35 
groups 5—32 
group-related » 5-2 
listed* A-—1 
normal + 5-32 
recommendations for minimum * 5~35 
requirements for security administrator « 5—1 
summary of * 5-32 
system 5-32 
user* 5-30 
using for file sharing» 8-18 
using to gain access 
and security audit» 4—41, 6—11 
vector * 5-32 
Privileged account» 5-35 
/PRIVILEGES qualifier 5-30 
PRMCEB privilege * A-6 
PRMGBL privilege *« A-7 
PRMMBxX privilege « A-7 
Prober 
how to catchs 5—23, 7-3 
Probing 
as security problems 1-1 
Process 
detached« 3-3 
privilege» 5-32, 5~35 
protection» 4-34 
reconnection * 3-5 
Process exclusion list» 6-19 
adding to lists 6-19 
Process rights list» 4-20 
Project accounts 5-13 
Propagation 
protection * 4-33, 4-35 
example * 8-21 
in directories * 4-21 
Protections 4-2 
See also Object protection 
See also Password protection 
access categorys 4—4 
bypassing checks * 4-6 
changings 4-13, 4-34 
default» 4-33, 4—34, 4-35 
managements 5-8, 5—11 
role of MFD for directories * 4-13 
of command procedures * 5—41 
of directories * 4-9 
of magnetic tape volumes * 4-12 
of volumes 4—2 


Prowction (Conr’G.) 
propagation of* 4-33, 4-35 
specification of » 4-6 
UlC-based* 4-2, 4-6 
Protection checking 
influenced by ownership « 5-8 
UIC-based* 4—4 
Protection code» C—1 
assigning during file creations 5-8 
Proxy access * 8—17 
Proxy accounts 3-18 
and VAXclusters * 9-3 
as captive accounts 8-14 
as restricted account 5-51 
example « 8-15, 8-20 
for multiple users * 3—19 
for single user * 3-19 
recommended restrictions > 8-14 
Proxy logins 3-3 
and circuit verification * 8-6 
and the user* 3—18 
establishment and management+ 8-13, 8-18 
key characteristic» 3-19 
PSWAPM privilege + A—7 
PURGE/ERASE command« 4—40 
/PWDLIFETIME qualifiers 5-17 
/PWDMINIMUM qualifiers 5-19 
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READ access* 4-5 

and directory file> 4—8 

and disk file» 4-8 

and READALL privilege * 4—7 

and volume * 4—10 
READALL privilege + 4-6, A-8 
Reconnection 

process * 3-5, 5-22 
Record 

displaying holder * 5-7 
Reference monitor 

applying to network» 8-1, 8-3 

concept in security * 2-1, 2-5 
Remote file access 

how to deny* 8-6 
REMOTE identifier» 4-19, 5-4 
Remote login» 3-2 

and system password» 5-15 
Remote security archive file» 6~9 
REMOVE/IDENTIFIER commande 5-6 
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REMOVE/PROXY command. 8-19 
REPLY/ENABLE=SECURITY commands 4—42 
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See System defined identifier 
Resource attribute > 4-29, 4-32, 5-13 
Resource monitoring * 6—1, 6-14 
action threshold * 6—17 
and disk space problems « 6-16 
by disk space» 6-18 
by message count» 6-18 
by percentage « 6-18 
by time * 6-18 
changing mode 6-18 
changing threshold values * 6-18 
disabling » 6-19 
overflowing the OPCOM mailbox » 6-15 
resume threshold * 6—17 
returning to normal conditions * 6-17 
running out of virtual memory * 6—20 
thresholds *» 6—16 
warning threshold + 6—16 
Restricted account 
danger of process spawning 5-48 
for network environment* 8—5 
Restriction 
login class * 3-16 
on command usages 5-31 
on mode of operation 5-31 
shift» 3-16 
work time « 5-30 
Retries 
controlling number for dialups * 5-22 
Rights database» 4-4, 4-15 
alarms « E-4 
creating and maintaining 5—5, 5-7 
display * 5-7 
Rights list» 4-20 
Rights of user 
displaying « 5—7 
RMS_FILEPROT parameter + 4-34, 5-8, 5~11 
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Scavenging 

disk» 4~39 
Secondary password « 3-12, 5-16 
Secure server* 3-13, 5-26 
Security 


See also Network security 
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Security (cont’d.) 
audit log file» 6-2 
for users * 3—1 
monitoring tools 
accounting log» 7-3 
object protection 
importance « 4—1 
physical 
of networks * 8-5 
Security administrator 
and cluster manager * 9-1 
goals of* 1-1 
personal accounts 5-1 
privilege requirements * 5—1 
Security alarm 
application» 4—41 
disabling on system console * 6—12 
Security alarm ACE* 4-21, 4-26 
specifying access * 4—27 
specifying options * 4—27 
Security archive file 
losing the remote link to» 6-20 
Security attack 
forms of * 7-1 
Security audit» 4—40, 7-3 
Security auditing» 6-1 
alarm failure mode * 6-4 
analyzing archive file » 6-10 
and OPCOM« 6-5 
archive file» 6—4, 6-9 
audit analysis * 6-13 
audit log file» 6—7 
audit server database» 6-4 
audit server process * 6-4 
changing disk monitor mode * 6-18 
components * 6-2, 6-3 
default audited events * 6—11 
disabling * 6-5 
disabling events * 6—11 
disabling resource monitoring» 6-19 
enabling events » 6-10 
listener device * 6-10 
mailbox * 6-10 
overviews 6-1 
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resource monitoring » 6-14 
restarting * 6-5 
terminal session * 6-21 
Security breach 
handling» 7-4 
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as alarm message * 6-1 
as audit message * 6-1 
Security feature 
account duration * 3-14 
auditing * 7-3 
break-in evasion * 3-17 
dialup retries * 3-16 
erase-on-delete * 5-43 
erasure patterns * 4—39 
highwater marking * 5-43 
passwords» 3-6 to 3-14, 5-14 to 5-20 
secure servers 3-13 
secure terminal server * 5-26 
security alarm* 4-41 
shift restrictions » 3-16 ‘ 
Security kernel 
defined* 2-2 
Security levels» 1-3 
Security model» 2-1 
Security operator 
terminal * 6-12 
SECURITY privilege» 5-15, A-8 
Security problem . 
anonymity of network and dialup users « 5-31 \ 
automatic login accounts 
how to reduce * 5-29 
categories of* 1—1 
network protected communications » 8-4 
telephone system as* 7—7 
SECURITY_AUDIT.AUDIT$JOURNAL + 6-4, 6-13 
Server 
secure terminal * 3-13 . 
SET ACLU/LIKE command» 4-35 f 
SET ACLIOBJECT=DEVICE command + 5-29 : 
SET ACL command: 4-17 
example * 5-12, 8-19 
with wildcards * 4~35 
SET AUDIT commands 4-42, 6-1 
alarms « E-17 
suggested auditing applications * 7-3 
SET DIRECTORY/ACL command 
example * 5—13 
SET FILE/ACL/DEFAULT command 
example « 8-19 
SET FILE/ERASE command: 4—40 
SET FILE/OWNER_UIC commands 4-32 
SET FILE/PROTECTION command: 4-33 
SET HOST command: 5-17 
SET PASSWORD/GENERATE command: 3-9, 
5-19 
SET PASSWORD/SECONDARY commands 3-12 


ee 


SET PASSWORD/SYSTEM/GENERATE command « 
5-15 
SET PASSWORD/SYSTEM commands 5-15 
SET PASSWORD command: 3-8 
SET PROCESS/PRIVILEGES commands 5-32 
SET PROTECTION/DEFAULT command: 4-34, 5-8 
SET PROTECTION/DEVICE commands 5-29, 5-30 
SET PROTECTION commands 4-13, 4-33, 5-12 
changing directory protection» 4—13 
SETPRV privilege > 5-32, A-8 
SET TERMINAL/DISCONNECT command: 5-22 
stopping password grabbers « 5-26 
SET TERMINAL/HANGUP command: 3-22 
SET TERMINAL/NOAUTOBAUD ¢ 3-7 
SET TERMINAL/NOMODEM/SECURE command ° 
. 5-26 
SET TERMINAL/SECURE commands 5-26 
SET TERMINAL/SYSPWD command: 5~—15 
SET VOLUME/ERASE_ON_DELETE command + 
5—43 
SET VOLUME/NOHIGHWATER command + 4-40 
SET VOLUME/NOHIGHWATER_MARKING 
command: 5-44 
SET VOLUME/OWNER_UIC command: 4-31 
SET VOLUME/PROTECTION command: 5-8 
Shared files 
considerations for a VAXcluster + 9-2 
SHARE privilege * A-8 
Shift restrictions * 3-16 
SHMEM privilege» A-8 
SHOW/IDENTIFIER/FULL command «+ 5-7 
SHOW/IDENTIFIER commands 5-7 
SHOW/RIGHTS commands 5-7 
SHOW ACL command: 4-17 
SHOW CHAR display » 8-16 
SHOW DEVICES/FULL commands 4-31 
SHOW INTRUSION commands 5-25 
SHOW PROCESS command 
and WORLD privilege « 5-39 
SHOW PROTECTION command: 4—34 
SHOW USERS command 
and disconnected jobs * 3-21 
Spawning of processes 
security implications in restricted accounts * 5—48 
Subdirectory ACL* 4-33 
Subjects 
in security model+ 2-1 
role in security * 2-2 
Surveillance guidelines > 5~—51 
Syntax 
identifier * 4-20 
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Syntax (cont’d.) 
protection code* 4-6 
UIC* 4-3 
SYS$ANNOUNCE « 5-21 
SYS$NODE « 5-21 
SYSSWELCOME « 5-21 
SYSALF.DAT * 5-27 
SYSECURITY.COM « 6-8 
SYSGBL privilege » A-9 
SYSLCK privilege » A-9 
SYSNAM privilege + A-9 
SYSPRV privilege» 4-6, A-9 
and SYSTEM category» 4—4 
effect on ownership privilege * 4-31 
System defined identifier * 4-19, 4-20 
System file 
auditing recommendations * 7—4 
System passwords 3-7, 5-15, 5-16 
as cause of login failures * 3-15 
disadvantages * 5-16 
guidelines » 5-16 
minimum length requirement» 5—19 
recommended change frequency *« 5—18 
where stored * 5-16 
System programs 
and ACL applications > 5—40 
SYSTEM user category > 4—4 
accessing magnetic tape * 4-6 
SYSUAF.DAT 
and rights database 5-5 
effect of changes on NETPROXY.DAT * 8-16 
normal protection « 5-20 
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Tampering with system file 
how to detect» 7-4 
Tape 
See Magnetic tape 
TCB (Trusted Computing Base) * D—1 
Terminal 
controlling access through system password « 
5-15 
hardcopy 
logout considerations * 3-21 
limiting access * 5-30 
logout considerations « 3-20 
operator * 6—12 
session 
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Terminal 

session (cont’d.) 

auditing» 6-21 

system password requirement for * 3-7 

usage restrictions > 5—29 

virtual 3-5 
Terminal concentrator 

effects on logins 3-2 
Terminal servers * 5-15 
Time-of-day restrictions 

for logins 3-16 
TMPMBxX privilege > A—10 
Traceback 

as security hazard* 5-34 
Training of user 

importance to security > 5-37 
Trojan horse» 4-44 

precautions against» 5-41 
Trusted Computing Base 

See TCB 
TTY_DEFCHARZ2 parameter 

disabling virtual terminals » 5-22 

enabling system passwords for remote login « 

5-15 

TTY_DEFPROT parameters 5-29 
TTY_OWNER parameter + 5-29 
TTY_TIMEOUT parameter 

setting reconnection time * 5-22 
Turnkey account 

See Captive account 
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UAF (user authorization file) 
and privileges » 5-32 
modifications 
and security audit» 4-41, 6-11 
modifying user data areas B—1 
UIC (user identification code) 
alphanumeric 
internal handling * 5-5 
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role in security » 2-3 

syntax* 4-3 

translation and storage* 4—4 

uniqueness requirement» 4—4 

for VAXcluster * 9-2 

UIC-based protection » 4—1 

changing» 4—12 

defined + 2-4 
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UIC-based protection (cont’d.) 
introduction tos 4—1 
UIC identifier» 4—19, 4—20 
deleted 
recognizing * 5-7 
User 
categories * 4—1 
defining password + 3-6 
granting privilege * 5-32 
introduction to system * 5-37 
security * 3—1 
User account» 5—1, 5-39 
User authorization file 
See UAF 
User categories * 4—4 
omission from protection code» 4—6 
sequence in which checked * 4-7 
User identification code 
See UIC 
User irresponsibility 
as security problems 1-1 
training as antidote * 5-37 
User name 
as identifier» 4-20 
revealed at logout* 3-21 
role in security» 2-3 
User penetration 
as security problems 1-2 
User probing 
as security problems» 1—1 
User rights 
displaying « 5-7 
User training * 5-37 f 
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VAXcluster 

security considerations * 9—1 
Verification 

of circuits 8-6 

of user identity 5-16 
Video terminal 

clearing screen 3-21 

logout considerations « 3-20 
Virtual terminal* 3-5, 5-22 

and logout* 3-22 

at logout time * 3-21 
VOLPRO privilege » A-10 ( 
Volume 

erasures * 5—43 
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Volume (cont’d.) 
protections 4-2, 4-12 
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Weekday 
restrictions for login» 3-16 
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How to Order Additional Documentation 





Technical Support 


If you need help deciding which documentation best meets your needs, call 800-343-4040 before placing 


your electronic, telephone, or direct mail order. 


Electronic Orders 


To place an order at the Electronic Store, dial 800-DEC-DEMO (800-332-3366) using a 1200- or 2400-baud 
modem. If you need assistance using the Electronic Store, call 800-DIGITAL (800-344-4825). 


Telephone and Direct Mail Orders 


Your Location Call 


Continental USA, 800-DIGITAL 
Alaska, or Hawaii 


Puerto Rico 809-754-7575 
Canada 800-267-6215 
International 

Internal? 


Contact 


Digital Equipment Corporation 
P.O. Box CS2008 
Nashua, New Hampshire 03061 


Local DIGITAL subsidiary 


Digital Equipment of Canada 

Attn: DECdirect Operations KAO2/2 
P.O. Box 13000 

100 Herzberg Road 

Kanata, Ontario, Canada K2K 2A6 


Local DIGITAL subsidiary or 
approved distributor 


SDC Order Processing - WMO/E15 
or 

Software Distribution Center 
Digital Equipment Corporation 
Westminster, Massachusetts 01473 


1For internal orders, you must submit an Internal Software Order Form (EN-01740-07). 


Reader’s Comments 


Guide to VMS System Security 
AA-LA40B-TE 





Please use this postage-paid form to comment on this manual. If you require a written reply to a software 
problem and are eligible to receive one under Software Performance Report (SPR) service, submit your 


comments on an SPR form. 
Thank you for your assistance. 


I rate this manual’s: 


Accuracy (software works as manual says) 
Completeness (enough information) 
Clarity (easy to understand) 

Organization (structure of subject matter) 
Figures (useful) 

Examples (useful) 

Index (ability to find topic) 

Page layout (easy to find information) 


I would like to see more/less 


What I like best about this manual is 


What I like least about this manual is 


I found the following errors in this manual: 


ae) 
da 
© 


Description 





| | 





Additional comments or suggestions to improve this manual: 


I am using Version 





Name/Title 
Company 
Mailing Address 


Excellent 


OOOO0O000O 


of the software this manual describes. 


Good 


OOOOO000 


Fair 


OOOO00o00 


Poor 


OOOO00000 





- Do Not Tear - Fold Here and Tape ———————-~——————————— 


No Postage 
Necessary 





fifo} i) tla] 


if Mailed 
in the 
United States 


BUSINESS REPLY MAIL 


_ FIRST CLASS PERMIT NO. 33 MAYNARD MASS. 





POSTAGE WILL BE PAID BY ADDRESSEE 


DIGITAL EQUIPMENT CORPORATION 
Corporate User Publications—Spit Brook 
ZKO1—3/J35 110 SPIT BROOK ROAD 
NASHUA, NH 03062-9987 


~ Do Not Tear - Fold Here ———————-—- ————— — — —— — —— — — - — —— — — — — - - - 





Cut Along Dotted Line 


a 


Reader’s Comments Guide to VMS System Security 
AA-LA4OB-TE 





Please use this postage-paid form to comment on this manual. If you require a written reply to a software 
problem and are eligible to receive one under Software Performance Report (SPR) service, submit your 
comments on an SPR form. 


Thank you for your assistance. 











I rate this manual’s: Excellent Good Fair Poor 
Accuracy (software works as manual says) O Oo O O 
Completeness (enough information) O O O C 
Clarity (easy to understand) O Cj CO O 
Organization (structure of subject matter) O O O O 
Figures (useful) O oO Oj C) 
Examples (useful) O C O 0 
Index (ability to find topic) O C] O O 
Page layout (easy to find information) O CO O O 
I would like to see more/less 

What I like best about this manual is 

What I like least about this manual is 

I found the following errors in this manual: 

Page Description 

Additional comments or suggestions to improve this manual: 

I am using Version of the software this manual describes. 

Name/Title ~W- CDept. 

Company ~~ eee (Date 


Mailing Address 
Phone 


— Do Not Tear - Fold Here and Tape ————————— -—-—-—----------—- 


fifo} i) ta] 





— Do Not Tear - Fold Here 


No Postage 
Necessary 


if Mailed 
in the 
United States 


BUSINESS REPLY MAIL 


FIRST CLASS PERMIT NO. 33 MAYNARD MASS. 


POSTAGE WILL BE PAID BY ADDRESSEE 


DIGITAL EQUIPMENT CORPORATION 
Corporate User Publications—Spit Brook 
ZKO1-—3/J35 110 SPIT BROOK ROAD 
NASHUA, NH 03062-9987 





Cut Along Dotted Line 


— 


